Choosing the Right API Gateway: Theory, Practice, and Real‑World Comparisons

1 API Gateway Basics

1.1 What is an API Gateway

API gateway is a server that serves as the single entry point of a system. From an object‑oriented design perspective it resembles the Facade pattern.

It encapsulates internal architecture and provides each client with a customized API, often handling authentication, monitoring, load balancing, caching, protocol conversion, rate limiting, and other cross‑cutting concerns.

The core idea is that all clients access microservices through a unified gateway, where non‑business functions are processed.

1.2 Main Functions of a Gateway

Microservice gateways act as a unified entry point and are divided into data plane and control plane:

Data plane handles incoming HTTP requests, routing, aggregation, protocol conversion, authentication, circuit breaking, gray release, logging, traffic monitoring, etc.

Control plane provides unified management and configuration, such as scaling, distributing configuration, tagging services, and exposing API contracts via Swagger.

Routing : forwards requests to target microservices, often using service discovery.

Load Balancing : distributes traffic using round‑robin, weight, or IP‑hash strategies.

Unified Authentication : centralizes SSO or token validation, relieving services from auth logic.

Protocol Conversion : bridges heterogeneous backends (REST, AMQP, Dubbo, etc.) to serve web, mobile, or open platforms.

Metrics Monitoring : records request counts, latency, health status, and can display dashboards (e.g., Hystrix).

Rate Limiting & Circuit Breaking : throttles excessive traffic and protects downstream services during spikes or failures.

Blacklist/Whitelist : filters malicious requests (e.g., DDoS) based on IP or other attributes.

Gray Release : controls traffic based on request tags for seamless version rollout.

Traffic Coloring : tags requests for downstream tracing and performance analysis.

Documentation Center : integrates Swagger to expose unified API specifications.

Log Auditing : captures request/response logs at URL granularity.

2 API Gateway Selection

2.1 Common API Gateways

Brief overview of popular gateways:

Nginx

Nginx is a high‑performance HTTP and reverse‑proxy server. It can serve static resources and, with Lua, provide flexible custom logic.

It uses a master‑worker architecture and asynchronous non‑blocking I/O to handle thousands of concurrent requests.

Zuul

Zuul is Netflix’s open‑source API gateway, integrates with Eureka, Ribbon, Hystrix, and fits into the Spring Cloud ecosystem.

Its core consists of filters that provide unified authentication, dynamic routing, load balancing, monitoring, and multi‑region elasticity.

Spring Cloud Gateway

Spring Cloud Gateway replaces Zuul 1, built on Spring 5, Spring Boot 2, and WebFlux (Netty). It claims 1.6× performance over Zuul and offers routing, load balancing, circuit breaking, authentication, path rewriting, logging, and built‑in rate‑limiting.

Kong

Kong is an open‑source gateway based on OpenResty (Nginx + Lua). It stores configuration in Cassandra or PostgreSQL, supports plugins for authentication, CORS, logging, rate limiting, etc., and scales horizontally.

Traefik

Traefik is a modern HTTP reverse proxy and load balancer written in Go. It auto‑discovers services from backends such as Docker, Kubernetes, Consul, etc., supports hot configuration reload, and provides built‑in metrics.

2.2 API Gateway Comparison

Community activity favors Kong and Traefik; maturity favors Kong, Tyk, and Traefik; performance favors Kong; architectural extensibility favors Kong, Tyk, and Ambassador, while Zuul integrates deeply with Spring Cloud.

Observations from practitioners: Nginx + Lua generally outperforms Java‑based gateways; maintainability depends on team expertise; high availability is achieved by multi‑node deployment with load balancers.

3 Custom Microservice Gateway Based on Traefik

This section describes an internally built gateway that extends Traefik.

3.1 Technology Stack

Traefik – lightweight reverse proxy with dynamic configuration.

Etcd – distributed key‑value store for configuration sharing and service discovery.

Go – language with strong concurrency, high performance, and simple syntax.

3.3 Gateway Architecture

The gateway consists of three parts:

Gateway Backend (hal‑fe & hal‑admin) – manages applications, services, and plugins, publishing configuration to Etcd.

Traefik – reads Etcd config, performs routing, and delegates authentication to hal‑agent.

Protocol Conversion Module – reads Etcd config, converts gRPC/Thrift requests, discovers downstream instances, and forwards traffic using load balancing.

3.4 Backend Details

Backend includes three modules:

Application – name, domain, path prefix, group, status.

Service – name, registration method, protocol type, group, status.

Plugin – name, type, configuration (e.g., path rewrite, auth).

Each application binds to one service but may have multiple plugins. Configurations are compiled into files stored in Etcd; they must follow Traefik’s official format.

3.5 Protocol Conversion Module

The hal‑proxy module handles service discovery, connection pooling, and protocol translation.

Problem Introduction

Key questions: how to discover downstream IP/port, how to reuse connections via a client pool, and how to support dynamic protocol conversion.

Implementation Principle

The Resolver module resolves service names to IPs and ports, caches them in memory, and updates periodically. Protocol modules initialize clients for each target and perform data conversion before forwarding. The connection pool uses a lock‑free ring buffer for high‑performance concurrency.

Implementation Logic

A diagram (omitted) shows interactions among core objects.