Why API Gateways Are Essential for Microservice Architectures

Background

In a microservice architecture a large application is split into many small services, each with its own database, framework, and possibly language. Front‑end clients (Web, H5, Android, iOS) call these services via REST APIs.

When a UI page, such as an e‑commerce product detail page, needs data from multiple services (product, price, inventory, reviews), the traditional database join cannot be used, creating challenges:

Multiple protocols (HTTP, AMQP, gRPC) may be used.

Service boundaries can change over time.

Service instances and host/port can be dynamic.

Front‑end requirements add further complications: coarse‑grained APIs are preferred, different client devices need different data, and network performance varies across devices.

API Gateway

An API gateway acts as the single entry point to the system, similar to the Facade pattern. It can provide customized APIs for each client and handle non‑functional concerns such as authentication, monitoring, load balancing, caching, request splitting, and static responses.

API gateways encapsulate internal architecture and expose a unified interface, often offering REST/HTTP access and managing service registration.

Chris Richardson classifies API gateways into two types:

Single‑node API gateway

Backends‑for‑Frontends (BFF) gateway

Single‑Node Gateway

This gateway provides different APIs for each client rather than a one‑size‑fits‑all API.

Backends‑for‑Frontends (BFF) Gateway

This pattern creates a dedicated gateway per client type.

Implementation Considerations

An API gateway typically handles routing, security, rate limiting, caching, logging, monitoring, retries, and circuit breaking. Under high concurrency it can become a performance bottleneck, and building a reliable, highly available gateway from scratch is a large effort.

Open‑source gateway projects include:

Tyk – Go‑based, fast and scalable.

Kong – Extensible via plugins, built on OpenResty.

Orange – Chinese OpenResty‑based gateway.

Netflix Zuul – JVM‑based edge service.

apiaxle – Node.js implementation.

api‑umbrella – Ruby implementation.

Many of these lack out‑of‑the‑box service aggregation, requiring custom extensions in Go, Lua, or Java, which may not be practical for all teams.

.NET Core developers often use Ocelot for API aggregation, but it has fewer features and can introduce performance issues.

Key missing capabilities in many gateways are timeout handling, circuit breaking, retries, and query aggregation.

Proposed Double‑Gateway Solution

Combine the strengths of two layers:

OpenResty API Gateway – Handles first‑level traffic, providing authentication, security, monitoring, rate limiting, service discovery, versioning, and routing.

Aggregation API Gateway – Built with Ocelot (or similar) to perform service aggregation, applying timeout, caching, circuit breaking, and retry policies.

Internal communication between the aggregation layer and microservices can use high‑performance protocols such as gRPC or AMQP.

Note: The aggregation layer is optional for some APIs; direct REST calls from the first‑level gateway are also possible.

Additional Topics

For cross‑service operations like order processing, an event bus (e.g., CAP) can be used to achieve eventual consistency in distributed transactions.

CAP (https://github.com/dotnetcore/CAP) provides an event‑bus and distributed‑transaction solution for .NET Core.

Conclusion

The API gateway is a crucial bridge in microservice architectures, providing a unified entry point, handling non‑functional concerns, and enabling service aggregation. Selecting the right open‑source gateway and combining it with an aggregation layer can address performance, scalability, and feature gaps.