Why API Gateways Are Essential for Microservices: Design Principles and Best Choices

1. Introduction

In a monolithic architecture, a client (Web or mobile) makes a single REST call to a backend, which is load‑balanced across N identical instances that query multiple databases and return a response. When the monolith is split into microservices, exposing each service directly to clients creates security issues and tight coupling.

Problems of direct client‑to‑microservice calls:

Client requirements often do not match the fine‑grained APIs exposed by each microservice.

Some services use non‑Web‑friendly protocols such as Thrift RPC or AMQP.

Refactoring microservices (merging or splitting) becomes difficult.

Exposing all backend services directly leads to poor scalability and manageability. An API gateway, positioned between the access layer and business services, addresses these issues.

1.1 What Is a Gateway?

A gateway acts as an API architecture that protects, enhances and controls access to API services. It sits in front of applications or services that provide REST APIs, handling authentication, access control and traffic limiting, making the underlying services transparent to callers.

1.2 Four Core Functions of an API Gateway

Request entry: the single entry point for all API requests.

Business aggregation: a unified point to invoke all backend services.

Policy mediation: implements security, authentication, routing, filtering, flow control, caching and other policies.

Unified management: provides configuration tools to manage the lifecycle and policies of all API services.

1.3 Role of the Gateway in Microservices

The gateway can be deployed per service instance, per service group, or for the entire architecture, simplifying the overall system complexity.

2. Gateway Design Ideas

An API gateway is not a typical business system; it is a middleware that adds capabilities such as request routing, service registration, load balancing, resilience design, security, gray release, API aggregation and orchestration.

Request routing – clients do not need to know the addresses of individual services.

Service registration – backend instances register their APIs so the gateway can route correctly.

Load balancing – supports round‑robin, weighted distribution, session stickiness, etc.

Resilience design – implements async processing, retries, idempotency, flow control, circuit breaking and monitoring.

Security – SSL termination, session validation, authorization, data validation and attack mitigation.

Gray release – directs traffic to different service versions for testing.

API aggregation – combines multiple backend calls into a single request to reduce client‑side round trips.

API orchestration – defines workflows that invoke a series of APIs, similar to serverless function chaining.

3. Gateway Design Focus

3.1 High Performance

The gateway must not become a bottleneck. Implementations often use high‑performance languages (C, C++, Go, Java) and asynchronous non‑blocking I/O (e.g., epoll, IOCP, Netty, Spring Reactor).

3.2 High Availability

Since all traffic passes through the gateway, it must be highly available and avoid single points of failure. Key practices include clustering, hot‑reloading configuration, and graceful restarts.

Clustering – the gateway should form its own cluster and synchronize data internally.

Service‑oriented configuration – support runtime configuration changes via an admin API.

Graceful restart – new requests are handled by new processes while old ones finish.

3.3 High Scalability

The gateway should be extensible to accommodate evolving business logic, often via plugins or modules (e.g., Nginx modules).

4. Gateway Design Considerations

Loose coupling with backend services; the gateway should only handle protocol headers, not business logic.

Application monitoring and distributed tracing to collect throughput, latency and error metrics.

Resilience features such as circuit breaking, rate limiting, retries and timeouts.

DevOps practices for automated testing, performance testing and fault‑tolerance.

5. Traffic Gateway

A traffic gateway controls inbound traffic to the cluster, handling global policies like traffic monitoring, logging, rate limiting, black‑/white‑listing and load balancing. Kong is a typical example.

6. Business Gateway

Business gateways sit closer to the application layer, providing functions such as authentication, logging, encryption, circuit breaking and API orchestration. Popular implementations include Zuul, Spring Cloud Gateway and others.

7. Common Gateway Comparison

7.1 OpenResty

OpenResty builds on Nginx and Lua, offering a high‑performance web platform for handling massive concurrency and extensibility via Lua scripts.

7.2 Kong

Kong, built on OpenResty, is a cloud‑native, scalable API gateway with features like authentication, traffic control, monitoring, request/response transformation, logging and serverless integration.

7.3 Zuul2.0

Zuul2 replaces the servlet‑based front end with Netty for asynchronous processing and introduces new filter naming (Inbound, Endpoint, Outbound). It offers high concurrency with low thread usage but adds complexity to debugging and tracing.

7.4 Spring Cloud Gateway

Spring Cloud Gateway, based on Spring 5, Spring Boot 2 and Project Reactor, provides a reactive, Netty‑based gateway with features such as dynamic routing, rate limiting, path rewriting, Hystrix integration and discovery client support.

8. Comparison of Several Gateways

Choosing a gateway depends on the business scenario, technology stack and performance requirements. Kong excels as a traffic gateway, Spring Cloud Gateway and Zuul2 are convenient for Java ecosystems, while OpenResty suits Lua‑based environments.

Author: Zhang Zhang Source: Architecture Advancement Road (ID: jiagou_jingjin)