KrakenD: Stateless API Gateway

By Khimananda Oli | Last reviewed: August 2026

Microservices architectures often introduce significant latency through chained HTTP calls and complex client-side orchestration. KrakenD: Stateless API Gateway solves this by acting as a high-performance aggregation layer that merges multiple backend responses into a single payload without maintaining any database or session state. This design eliminates the gateway as a bottleneck, allowing you to scale horizontally with predictable linear performance. If you are building distributed systems and need to understand how to manage traffic efficiently, reviewing general API gateways for microservices provides necessary context before diving into KrakenD’s specific stateless implementation.

How does KrakenD: Stateless API Gateway achieve sub-millisecond overhead?

Most API gateways rely on embedded databases, Redis caches, or shared session stores to manage rate limits, authentication tokens, and routing rules. These dependencies create network hops and serialization costs that accumulate under load. KrakenD: Stateless API Gateway takes a fundamentally different approach by compiling all logic into memory at startup from a single declarative JSON or YAML configuration file. Once running, the gateway performs zero external lookups for routing decisions; everything exists in the process memory of each instance.

This architecture means every gateway node is identical and completely independent. There is no leader election, no cluster synchronization, and no distributed consensus protocol slowing down requests. When you need more capacity, you simply add another replica. The overhead per request typically stays below 0.5ms because the gateway is essentially executing pre-computed hash table lookups and concurrent HTTP fetches rather than dynamic scripting or database queries. For teams accustomed to tuning Nginx versus Apache performance, KrakenD operates closer to Nginx’s event-driven model but with native application-layer aggregation logic built directly into the binary.

Memory-only configuration loading

The configuration file is validated and loaded entirely into RAM during the boot sequence. Invalid configurations prevent startup entirely, following the "fail-fast" principle critical for production reliability. This eliminates runtime parsing overhead and ensures that every request path is optimized before the first byte arrives. In my experience managing SOC 2 compliant environments, this immutability also simplifies audit trails: the exact configuration hash deployed matches the artifact in your Git repository, with no possibility of runtime drift or manual hotfixes.

How do you configure endpoint aggregation in KrakenD?

Aggregation is the primary reason engineers adopt KrakenD: Stateless API Gateway. Instead of forcing mobile clients to make three sequential calls to fetch user profile, recent orders, and loyalty points, you define a single gateway endpoint that fetches all three in parallel and merges the results. The configuration uses a declarative JSON structure where each endpoint specifies its backend origins.

{
  "version": 3,
  "endpoints": [
    {
      "endpoint": "/dashboard/{user_id}",
      "method": "GET",
      "concurrent_calls": 3,
      "backend": [
        {
          "host": ["http://user-service:8080"],
          "url_pattern": "/api/v1/users/{user_id}",
          "mapping": "profile"
        },
        {
          "host": ["http://order-service:8080"],
          "url_pattern": "/api/v1/orders?user={user_id}&limit=5",
          "mapping": "recent_orders"
        },
        {
          "host": ["http://loyalty-service:8080"],
          "url_pattern": "/points/{user_id}",
          "mapping": "loyalty"
        }
      ]
    }
  ]
}

The concurrent_calls parameter tells KrakenD how many goroutines to spawn simultaneously. Each backend response gets nested under its mapping key in the final JSON response. If one backend fails, KrakenD returns partial data with appropriate metadata rather than failing the entire request—unless you explicitly configure strict merging. This resilience pattern aligns well with circuit breakers and resilience patterns you may already implement at the service level.

1. Define the public-facing endpoint URL and HTTP method in the endpoints array.
2. List each microservice under backend with its internal host and URL pattern.
3. Set mapping to namespace each backend’s response and avoid key collisions.
4. Configure concurrent_calls to match the number of backends for true parallel execution.
5. Add optional timeout, sd (service discovery), or extra_config for rate limiting and security headers.

How does KrakenD compare to Kong, NGINX, and AWS API Gateway?

Choosing a gateway requires understanding trade-offs beyond raw throughput. While KrakenD: Stateless API Gateway excels at aggregation and horizontal scaling, other tools serve different niches. Kong offers extensive plugin ecosystems and Lua-based extensibility but introduces PostgreSQL/Cassandra dependencies for its control plane. NGINX remains unmatched for pure reverse proxying and TLS termination but lacks native response aggregation. AWS API Gateway integrates deeply with Lambda and IAM but carries higher per-request costs and vendor lock-in.

In practice, I recommend KrakenD when your primary pain point is client-side waterfall calls and you want infrastructure-level aggregation without writing custom code. If you need OAuth2 provider integration, billing plugins, or multi-tenant admin UIs out-of-the-box, Kong’s ecosystem may justify its operational complexity. For teams already standardized on AWS, the managed gateway reduces operational toil despite higher unit costs—a trade-off worth quantifying against your expected request volume.

How do you deploy and scale KrakenD in Kubernetes?

Deploying KrakenD: Stateless API Gateway in Kubernetes leverages its stateless nature perfectly. Since no persistent volumes or inter-pod communication is required, you can treat it as a standard Deployment with aggressive Horizontal Pod Autoscaler (HPA) targets. Mount the configuration via a ConfigMap and use the official Docker image, which includes health check endpoints at /__health and metrics at /__stats.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: krakend-gateway
spec:
  replicas: 3
  selector:
    matchLabels:
      app: krakend
  template:
    metadata:
      labels:
        app: krakend
    spec:
      containers:
      - name: krakend
        image: devopsfaith/krakend:2.9
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: config
          mountPath: /etc/krakend
        livenessProbe:
          httpGet:
            path: /__health
            port: 8080
          initialDelaySeconds: 5
        resources:
          requests:
            cpu: 250m
            memory: 256Mi
          limits:
            cpu: "1"
            memory: 512Mi
      volumes:
      - name: config
        configMap:
          name: krakend-config

For observability, enable OpenTelemetry export in your KrakenD config to feed traces directly into Jaeger or Tempo. This gives you end-to-end visibility from client request through gateway aggregation to individual backend services. Proper OpenTelemetry instrumentation at the gateway layer catches aggregation bottlenecks that service-level metrics alone cannot reveal. Pair this with Prometheus scraping of the /__stats endpoint to build dashboards tracking concurrent call distributions, backend error rates, and p99 latency percentiles.

Scaling considerations for Nepal and emerging markets

For teams operating in Nepal or similar regions where cloud egress costs and bandwidth constraints matter, KrakenD’s efficiency translates directly to cost savings. Because it aggregates responses server-side within your VPC or data center, mobile clients receive smaller payloads over expensive or unreliable connections. A dashboard that would normally require 150KB across three round-trips might compress to 40KB in a single response. This architectural choice improves user experience on 3G networks while reducing CDN egress bills—a practical optimization often overlooked in gateway selection.

When should you avoid KrakenD: Stateless API Gateway?

No tool fits every scenario. KrakenD’s statelessness becomes a limitation when you need features that inherently require shared state. If your architecture demands centralized rate limiting across all gateway instances (e.g., "user X gets 100 requests/hour globally regardless of which pod handles them"), you must integrate an external Redis or use the enterprise version’s Redis adapter. Similarly, if you need dynamic route registration via REST API without redeploying configuration, KrakenD’s immutable config model requires a CI/CD pipeline update instead.

Complex transformation logic involving conditional branching, loops, or database lookups during request processing falls outside KrakenD’s declarative scope. While CEL (Common Expression Language) expressions handle basic field manipulation and filtering, anything resembling business logic belongs in a dedicated backend service or a sidecar. Treat the gateway as a dumb pipe with fast plumbing, not an application runtime. This discipline keeps your gateway performant and your compliance boundaries clean—auditors prefer infrastructure components that don’t contain mutable business rules.

Implementing KrakenD: Stateless API Gateway in Production

Adopting KrakenD: Stateless API Gateway succeeds when you embrace its constraints as features rather than limitations. Start by identifying your highest-latency client endpoints that chain multiple service calls; these yield immediate wins from aggregation. Version your configuration in Git alongside your infrastructure code, and validate it in CI using the krakend check command before deployment. Monitor backend timeout distributions aggressively—the gateway’s concurrency model exposes slow services that sequential clients masked. Finally, pair your gateway rollout with proper SLIs and SLOs to quantify whether aggregation actually improves user-perceived latency versus introducing new failure modes.

If you are evaluating gateway options for a microservices platform or need help designing a stateless aggregation layer that passes compliance audits, reach out to discuss your architecture. Getting the gateway strategy right early prevents costly rewrites when traffic scales.