Apache APISIX as API Gateway for Microservices

Setup Apache APISIX as API Gateway for Microservices

We constantly encounter situations where a microservice architecture grows, and plain Nginx or HAProxy can no longer handle dynamic routing. Years of experience with API gateways have shown: Apache APISIX is the best solution for flexible traffic management without downtime. We guarantee that after setup you'll forget about manual config edits and downtime on every deploy.

APISIX is a high-performance API gateway built on OpenResty (Nginx + LuaJIT) with etcd as the configuration store. Its main difference from Kong and other solutions is that configuration changes apply without reloading, and route update latency is measured in milliseconds. For dynamic microservice environments where deploys happen dozens of times a day, that's significant. Our engineers are certified and have set up APISIX on projects with 50,000 RPS load.

Why Apache APISIX is Faster Than Other API Gateways?

APISIX is 2x faster than Kong in scenarios with frequent route updates thanks to etcd and hot-reload plugins. Plugins execute on LuaJIT without context switching, giving about 1 ms latency per request even with a dozen active plugins. For high-load systems, that's critical.

Architecture and Components

APISIX consists of three key parts: data plane (traffic processing), control plane (Admin API + Dashboard), and etcd (configuration storage). In production, the data plane is deployed with at least two instances behind a load balancer; the control plane is isolated from external access. The etcd cluster should include at least three replicas for fault tolerance and fast consistency.

Kubernetes deployment via Helm:

helm repo add apisix https://charts.apiseven.com
helm repo update
helm install apisix apisix/apisix \
  --namespace ingress-apisix \
  --create-namespace \
  --set gateway.type=LoadBalancer \
  --set ingress-controller.enabled=true \
  --set etcd.replicaCount=3 \
  --set apisix.replicaCount=2

After installation, the Admin API is available on 9180/tcp — only inside the cluster. We never expose it externally.

Routing and Upstream Configuration

Creating an upstream and route via Admin API:

# Upstream — backend pool
curl -X PUT http://apisix:9180/apisix/admin/upstreams/1 \
  -H "X-API-KEY: $ADMIN_KEY" \
  -d '{
    "type": "roundrobin",
    "nodes": {
      "orders-svc.default.svc.cluster.local:8080": 1,
      "orders-svc-v2.default.svc.cluster.local:8080": 1
    },
    "checks": {
      "active": {
        "http_path": "/health",
        "interval": 5,
        "successes": 2,
        "http_failures": 3
      }
    }
  }'

# Route — traffic matching rule
curl -X PUT http://apisix:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: $ADMIN_KEY" \
  -d '{
    "uri": "/api/v1/orders/*",
    "host": "api.example.com",
    "upstream_id": 1,
    "plugins": {
      "rate-limiting": {
        "count": 1000,
        "time_window": 60,
        "key": "consumer_name"
      },
      "jwt-auth": {},
      "prometheus": {}
    }
  }'

Health checks are built into upstreams — APISIX automatically removes unhealthy nodes from load balancing. This is critical during rolling deploys: while a new pod hasn't passed readiness probes, old nodes keep handling traffic.

Plugin Architecture

APISIX's strength is in its plugins. Out of the box: authentication (JWT, OAuth 2.0, API key, LDAP), rate limiting with multiple strategies (consumer, IP, service), request/response transformation, circuit breaker, tracing via OpenTelemetry and Zipkin, metrics for Prometheus.

Example of a circuit breaker configuration to protect against cascading failures:

"api-breaker": {
  "break_response_code": 503,
  "max_breaker_sec": 30,
  "unhealthy": {
    "http_statuses": [500, 502, 503],
    "failures": 5
  },
  "healthy": {
    "http_statuses": [200],
    "successes": 3
  }
}

Five consecutive errors open the circuit; requests get 503 without hitting the backend. Three successful responses after the timeout close the circuit. The backend service gets time to recover.

Custom plugins can be written in Lua or via plugin runner in Go/Python/Java. This sets APISIX apart from solutions where extending requires forking the code.

How to Set Up Canary Deployment with APISIX?

In Kubernetes, configuration via CRDs is more natural than direct API calls:

---
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: orders-route
spec:
  http:
    - name: orders
      match:
        hosts:
          - api.example.com
        paths:
          - /api/v1/orders/*
      backends:
        - serviceName: orders-svc
          servicePort: 8080
          weight: 90
        - serviceName: orders-svc-v2
          servicePort: 8080
          weight: 10
      plugins:
        - name: jwt-auth
          enable: true
        - name: prometheus
          enable: true
---

A 10%/90% canary between service versions is managed via weight — no manual changes when gradually rolling out a new version.

How Does APISIX Scale Under Load?

The APISIX data plane scales horizontally by adding replicas behind a load balancer. For dynamic scaling in Kubernetes, we use HPA based on CPU or RPS metrics. The etcd cluster also scales — we recommend 3, 5, or 7 nodes depending on load. As the number of routes grows (up to 5000+), etcd maintains stable performance.

What's Included in the Work

We'll assess your project. As part of a turnkey setup:

• Topology design: number of data plane replicas, control plane isolation, etcd configuration storage scheme.
• Installation in Kubernetes or bare metal.
• Migration of existing nginx/HAProxy rules to APISIX configuration.
• Setup of authentication, rate limiting, and observability (Prometheus + Grafana dashboard).
• Load testing with failover simulation.
• Documentation of administrative procedures.

Cost is calculated individually after an audit. Contact us for a consultation on your project. Request an audit of your infrastructure — we'll identify bottlenecks and choose the optimal configuration. 5+ years of experience with APISIX and 30+ implementations guarantee results.