Design of a Microservice API Gateway: Functional and Non‑Functional Considerations

In the context of microservice architecture, a gateway must handle routing, load balancing, aggregation, authentication, rate limiting, circuit breaking, caching, retries, logging, and management, while also meeting non‑functional requirements such as high performance, high availability, scalability, and observability.

Routing : Requests are forwarded based on host, URL, or other rules. Two implementation options are discussed – storing routing rules in a database (with optional Redis caching) or in configuration files (potentially managed by a configuration server for hot updates).

Load Balancing : Various algorithms are listed (random, weighted random, round‑robin, weighted round‑robin, least connections, source‑IP hash). For microservices, source‑IP hash is recommended because it avoids session‑sharing issues and is simple to implement.

Aggregation Services : Two approaches are presented – using GraphQL (with three deployment options) or implementing aggregation directly in code. Due to GraphQL’s learning curve and limited aggregation needs, coding the aggregation in the gateway is preferred.

Authentication & Authorization : RBAC (Role‑Based Access Control) is the dominant model. The article suggests using the basic RBAC0 model and adopting Spring Security for Java‑based gateways.

Overload Protection & Rate Limiting : Rate‑control mechanisms such as token‑bucket and leaky‑bucket algorithms are recommended, with token‑bucket being suitable for handling bursts. Nginx can provide basic rate limiting if no custom requirements exist.

Circuit Breaking : Describes the typical circuit‑breaker lifecycle (open → half‑open → closed) and advises using mature open‑source libraries.

Service Degradation : Proposes a queue‑based degradation strategy where requests exceeding a threshold are either rejected or processed based on configurable rules, again suggesting the use of existing open‑source solutions.

Caching : Recommends a centralized cache (e.g., Redis) for gateway data, outlines cache hit/miss flow, and warns about cache avalanche, penetration, and breakdown.

Service Retries : Requires configuration (which endpoints, timeout, retry count) and execution logic; suggests leveraging existing libraries.

Logging : Follow project logging standards; initial access logs can be captured via Nginx.

High Performance : Thread‑per‑request models are inefficient for gateways; a Reactor model (e.g., Netty) is advocated.

High Availability : Includes graceful shutdown, slow‑start, and ensures the gateway can handle traffic spikes without overwhelming newly started instances.

Scalability & Extensibility : Emphasizes a filter/interceptor architecture with global and business‑specific interceptors, priority ordering, and dynamic configuration via APIs or a configuration server.

Elasticity : Recommends a stateless gateway design, using token‑based authentication to decouple user state and enable easy horizontal scaling.

Monitoring : Suggests integrating with tools like SkyWalking, Pinpoint, or ELK for observability and log analysis.