Comparative Analysis of Open‑Source API Gateways: Architecture, Features, and Performance

In microservice architectures, an API gateway is a common pattern to address issues such as mismatched API granularity, diverse client requirements, network performance differences, dynamic service instances, and protocol heterogeneity.

The article lists typical gateway functions: reverse proxy and routing, load balancing, authentication/authorization, IP whitelist/blacklist, performance analytics, rate limiting, request transformation, version control, circuit breaking, multi‑protocol support, caching, and API documentation.

To evaluate several open‑source gateways, four sample services (Go, Node.js, Python Flask, Java Spring) were created using an OpenAPI‑defined petstore and containerised with Docker Compose.

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    get:
      summary: List all pets
      operationId: listPets
      parameters:
        - name: limit
          in: query
          description: How many items to return at one time (max 100)
          required: false
          schema:
            type: integer
            format: int32
      responses:
        '200':
          description: A paged array of pets
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Pets"
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
    post:
      summary: Create a pet
      operationId: createPets
      responses:
        '201':
          description: Null response
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
  /pets/{petId}:
    get:
      summary: Info for a specific pet
      operationId: showPetById
      parameters:
        - name: petId
          in: path
          required: true
          description: The id of the pet to retrieve
          schema:
            type: string
      responses:
        '200':
          description: Expected response to a valid request
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Pet"
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
components:
  schemas:
    Pet:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        tag:
          type: string
    Pets:
      type: array
      items:
        $ref: "#/components/schemas/Pet"
    Error:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string

The services were deployed via the following Docker‑Compose file.

version: "3.7"
services:
  goapi:
    container_name: goapi
    image: naughtytao/goapi:0.1
    ports:
      - "18000:8080"
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 256M
        reservations:
          memory: 256M
  nodeapi:
    container_name: nodeapi
    image: naughtytao/nodeapi:0.1
    ports:
      - "18001:8080"
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 256M
        reservations:
          memory: 256M
  flaskapi:
    container_name: flaskapi
    image: naughtytao/flaskapi:0.1
    ports:
      - "18002:8080"
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 256M
        reservations:
          memory: 256M
  springapi:
    container_name: springapi
    image: naughtytao/springapi:0.1
    ports:
      - "18003:8080"
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 256M
        reservations:
          memory: 256M

Each gateway was then configured to route requests to the appropriate backend service, and performance was measured with k6 under 100 concurrent users issuing 1000 requests.

Nginx

Nginx is an asynchronous web server and reverse proxy written in C. Its architecture consists of a master process, multiple worker processes, and an optional proxy cache. Routing to the four services is achieved with rewrite and proxy_pass directives.

server {
    listen 80 default_server;
    location /goapi {
        rewrite ^/goapi(.*) $1 break;
        proxy_pass http://goapi:8080;
    }
    location /nodeapi {
        rewrite ^/nodeapi(.*) $1 break;
        proxy_pass http://nodeapi:8080;
    }
    location /flaskapi {
        rewrite ^/flaskapi(.*) $1 break;
        proxy_pass http://flaskapi:8080;
    }
    location /springapi {
        rewrite ^/springapi(.*) $1 break;
        proxy_pass http://springapi:8080;
    }
}

k6 testing showed an average of about 1 093 requests per second, essentially matching the direct‑service baseline.

Kong

Kong builds on Nginx and OpenResty, using Lua for plugins and PostgreSQL for configuration storage. It offers a rich plugin ecosystem for authentication, caching, monitoring, and more. Services and routes are created via its Admin API.

curl -i -X POST http://localhost:8001/services \
    --data name=goapi \
    --data url='http://goapi:8080'
curl -i -X POST http://localhost:8001/services/goapi/routes \
    --data 'paths[]=/goapi' \
    --data name=goapi

Performance testing yielded roughly 705 requests per second, lower than Nginx due to the overhead of additional features.

APISIX

APISIX is a cloud‑native gateway written in Lua, storing configuration in etcd. It supports dynamic routing, gRPC, WebSocket, rate limiting, hot‑reloading of plugins, and integrates with Prometheus, SkyWalking, and Zipkin for observability.

version: "3.7"
services:
  apisix-dashboard:
    image: apache/apisix-dashboard:2.4
    ports:
      - "9000:9000"
    volumes:
      - ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml
  apisix:
    image: apache/apisix:2.3-alpine
    ports:
      - "8080:9080"
      - "9443:9443"
    volumes:
      - ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml:ro
    depends_on:
      - etcd
  etcd:
    image: bitnami/etcd:3.4.9
    environment:
      - ETCD_ENABLE_V2="true"
      - ALLOW_NONE_AUTHENTICATION="yes"
    ports:
      - "2379:2379"

k6 results reached about 1 155 requests per second, close to the baseline and demonstrating the efficiency of the cloud‑native design.

Tyk

Tyk is a Go‑based gateway that uses Redis for its data store. It provides a commercial dashboard but also supports full API management via REST calls.

version: '3.7'
services:
  tyk-gateway:
    image: tykio/tyk-gateway:v3.1.1
    ports:
      - "8080:8080"
    volumes:
      - ./tyk.standalone.conf:/opt/tyk-gateway/tyk.conf
    environment:
      - TYK_GW_SECRET=foo
    depends_on:
      - tyk-redis
  tyk-redis:
    image: redis:5.0-alpine
    ports:
      - "6379:6379"

k6 testing produced 400‑600 requests per second, comparable to Kong’s performance.

Zuul

Zuul is Netflix’s Java‑based gateway component. It relies on a chain of filters (pre, route, post, error) written in Groovy or Java and integrates with Ribbon for load balancing, Hystrix for circuit breaking, and other Netflix OSS libraries. Routes are defined in Spring Boot properties.

class DeviceDelayFilter extends ZuulFilter {
    static Random rand = new Random()
    @Override
    String filterType() { return 'pre' }
    @Override
    int filterOrder() { return 5 }
    @Override
    boolean shouldFilter() {
        return RequestContext.getRequest().getParameter("deviceType").equals("BrokenDevice")
    }
    @Override
    Object run() {
        sleep(rand.nextInt(20000)) // Sleep for a random number of seconds between [0-20]
    }
}

Initial tests on a single‑core container achieved only ~200 RPS; after allocating 4 cores and 2 GB memory, performance improved to 600‑800 RPS, highlighting the resource‑intensive nature of the synchronous servlet model.

Gravitee

Gravitee is a Java‑based API management platform offering an open‑source gateway, management API, and UI. It stores data in MongoDB and Elasticsearch and provides a graphical studio for designing APIs.

# Docker‑Compose for Gravitee stack
version: '3.7'
networks:
  frontend:
    name: frontend
  storage:
    name: storage
volumes:
  data-elasticsearch:
  data-mongo:
services:
  mongodb:
    image: mongo:3.6
    container_name: gio_apim_mongodb
    volumes:
      - data-mongo:/data/db
    networks:
      - storage
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.7.0
    container_name: gio_apim_elasticsearch
    environment:
      - http.host=0.0.0.0
      - transport.host=0.0.0.0
      - xpack.security.enabled=false
      - cluster.name=elasticsearch
      - discovery.type=single-node
    volumes:
      - data-elasticsearch:/usr/share/elasticsearch/data
    networks:
      - storage
  gateway:
    image: graviteeio/apim-gateway:3
    container_name: gio_apim_gateway
    ports:
      - "8082:8082"
    depends_on:
      - mongodb
      - elasticsearch
    environment:
      - gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee
    networks:
      - storage
      - frontend
  management_api:
    image: graviteeio/apim-management-api:3
    container_name: gio_apim_management_api
    ports:
      - "8083:8083"
    depends_on:
      - mongodb
      - elasticsearch
    environment:
      - gravitee_management_mongodb_uri=mongodb://mongodb:27017/gravitee
    networks:
      - storage
      - frontend
  management_ui:
    image: graviteeio/apim-management-ui:3
    ports:
      - "8084:8080"
    depends_on:
      - management_api
    networks:
      - frontend
  portal_ui:
    image: graviteeio/apim-portal-ui:3
    ports:
      - "8085:8080"
    depends_on:
      - management_api
    networks:
      - frontend

On a single‑core container the gateway handled about 200 RPS with occasional errors; scaling to 4 cores raised throughput to 500‑700 RPS, still lagging behind the lighter‑weight gateways.

Conclusion

The comparative study shows that while Nginx offers the highest raw performance with minimal features, cloud‑native gateways such as APISIX provide a good balance of extensibility and speed. Java‑based solutions (Zuul, Gravitee) are more resource‑hungry, and Go‑based Tyk delivers solid performance with a simpler licensing model. The choice of gateway should consider required features, deployment environment, and performance constraints.