Essential API Gateway Requirements for Scalable Microservices

Concept

API Gateway (API GW) is a unified entry point that exposes internal services to external clients, acting as the system’s sole access point. It predates microservices and has been used in banking, securities, and other domains as a front‑end gateway.

From a façade pattern perspective, the gateway encapsulates internal architecture, providing customized APIs per client and handling responsibilities such as authentication, monitoring, load balancing, caching, request splitting, static response handling, traffic control, logging, retry, and circuit breaking.

In microservice scenarios, the gateway’s role remains the same: it serves as the entry point for all non‑business functions.

Functional Requirements

Routing

The gateway must route incoming requests to the appropriate microservice, supporting dynamic rule configuration to avoid service downtime caused by gateway restarts.

Load Balancing

When services are deployed in clusters, the gateway must distribute requests among instances. Dynamic algorithm adjustment is generally unnecessary, though multiple algorithms may be supported.

Routing matches a request to a target service, while load balancing selects an instance among multiple identical service instances.

Service Aggregation

To reduce multiple client calls, the gateway should aggregate responses from several microservices into a single response, offering benefits such as decoupling, targeted optimization, simplified client logic, and performance gains, while incurring development, testing, and availability overhead.

Pros : decoupling, targeted optimization, simplified client logic, performance improvement.

Cons : additional development effort, potential impact on high availability (frequent releases, code errors).

Authentication & Authorization

The gateway must provide robust authentication and authorization. Permissions are treated as resources and can be divided into operation permissions (CRUD actions) and data permissions (access to specific data). Further granularity includes page permissions and menu permissions.

Overload Protection

To prevent system overload, the gateway should implement traffic control, circuit breaking, and service degradation.

Traffic Control

Limit concurrent requests or request rates per time window, configurable per user, application, or exception, with granularity of minute, hour, or day.

Circuit Breaking

When a service becomes unresponsive or slow, the gateway immediately returns a predefined response, avoiding request backlog, and periodically attempts to restore service.

Service Degradation

During overload, non‑core services can be degraded to preserve core service availability, with automatic restoration once load normalizes.

Caching

Cache frequently called, rarely changing responses to reduce request chains, response time, and backend load, while managing cache synchronization and operational costs.

Service Retry

Automatically retry failed requests a configurable number of times to improve availability in case of transient network issues.

Logging

Record request logs for statistical analysis and troubleshooting.

Management UI

Provide interfaces for routing configuration, service degradation, call statistics, deployment management, etc.

Non‑Functional Requirements

Security

Ensure secure communication, data encryption, integrity, and non‑repudiation to protect exposed services.

Performance

The gateway handles all inbound traffic; poor performance makes it a bottleneck, often requiring horizontal scaling and additional hardware.

High Availability

Target availability of 99.99% (four nines) or higher, limiting annual downtime to minutes.

Scalability & Elasticity

Design the gateway to be stateless and support hot deployment for seamless scaling and feature updates.

Monitoring

Track metrics such as request volume, latency, error rates, and support custom alerts and analytical reports.

Priority of Requirements

Core functions: routing, load balancing, authentication/authorization, overload protection. Essential non‑functional attributes: high performance, high availability, scalability. Features like aggregation, caching, retry, extensibility, and management can be phased in later.

Conclusion

This article outlines the essential requirements for a microservice API gateway; the next piece will discuss its design.