In the previous chapter, we learned how services find each other through service discovery.

But consider what happens when external clients, like mobile apps or web browsers, need to interact with your microservices. Should a mobile app call a dozen different services to load a single screen? Should every service implement its own authentication, rate limiting, and SSL termination? The answer to both questions is no.

The API Gateway pattern provides a single entry point for all external clients. Instead of exposing your microservices directly, you place a gateway in front of them that handles routing, security, and other cross-cutting concerns.

The gateway simplifies client interactions and centralizes functionality that would otherwise be duplicated across services.

In this chapter, you will learn:

The API Gateway is one of the most common patterns in microservices architectures. Understanding it is essential for designing scalable, secure, and maintainable systems.

The Problem: Direct Client-to-Service Communication

Imagine a mobile app for an e-commerce platform. The home screen shows product recommendations, the user's cart, recent orders, and promotional banners. Without an API Gateway, the app would need to call multiple services directly.

This approach creates several problems:

Too Many Requests

The client makes multiple round trips over the network. Mobile networks are slow and unreliable. Each request adds latency, increases battery drain, and risks failure.

Tight Coupling

Clients are coupled to the internal service structure. If you split the Order Service into Order and Shipping services, every client must be updated.

Duplicated Cross-Cutting Concerns

Every service must implement authentication, authorization, rate limiting, logging, and SSL. This duplicates code and creates inconsistency.

Protocol Mismatch

Internal services might use gRPC, AMQP, or other protocols. External clients typically expect REST or GraphQL over HTTPS.

The Solution: API Gateway