Understanding API Gateways in Microservice Architecture and Practical Implementation Options

Background

In a microservice architecture a large application is split into many small services, each potentially having its own database, framework, and language, and exposing REST APIs for H5, Android, iOS, and third‑party clients.

When a UI needs to display data that resides in several services—such as a product detail page showing title, price, stock, and reviews—aggregating these calls becomes difficult because traditional database joins are unavailable.

Problem

Microservices may use different protocols (HTTP, AMQP, gRPC), evolve over time, and have dynamic instances or host/port information, making direct client calls cumbersome. UI requirements often demand coarse‑grained APIs, device‑specific data, and efficient network usage.

API gateway is a server that acts as the single entry point to a system, similar to the Facade pattern. It encapsulates internal architecture, provides customized APIs for each client, and can handle authentication, monitoring, load‑balancing, caching, request shaping, static responses, etc.

API Gateway Types

According to Chris Richardson, there are two main types:

Single‑node API gateway

Backends‑for‑frontends (BFF) gateway

Single‑node Gateway

This model provides different APIs for each client rather than a one‑size‑fits‑all API, similar to the gateway used in Microsoft’s eShop sample.

Backends‑for‑frontends (BFF) Gateway

This pattern creates a dedicated gateway for each client type, allowing tailored aggregation and transformation of backend services.

Implementation Options

Several open‑source API gateway projects are available:

Tyk : Go‑based, fast, scalable, with a management portal.

Kong : Extensible, plugin‑driven gateway built on OpenResty.

Orange : Chinese OpenResty‑based gateway.

Netflix Zuul : JVM‑based edge service offering dynamic routing, monitoring, resilience, and security.

apiaxle : Node.js implementation.

api‑umbrella : Ruby implementation.

These projects often lack out‑of‑the‑box service aggregation; extending them requires Go (Tyk), Lua (Kong), or Java (Zuul) expertise.

ASP.NET Core developers may consider Ocelot for API aggregation, but it has limited features compared with the above gateways and may become a performance bottleneck.

Proposed Dual‑Gateway Solution

The author suggests combining the strengths of both layers:

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

Aggregation API Gateway (e.g., Ocelot) : Performs service composition, applying timeout, caching, circuit‑breaker, and retry policies, and communicates with backend services via high‑performance protocols such as gRPC or AMQP.

Distributed Transactions

For cross‑service operations like an e‑commerce order that touches product, pricing, and inventory services, the article recommends using an event‑bus (e.g., CAP) to achieve eventual consistency. CAP provides distributed transaction support for .NET Core.

Conclusion

The article clarifies the essential role of API gateways in microservice architectures, reviews open‑source options, and presents a practical dual‑gateway implementation that balances high‑performance I/O, scalability, and feature completeness.