As we discussed earlier, microservices tend to accumulate a lot of repeated concerns unrelated to their responsibilities. If something repeats across services, we should try to move it into a separate service that clients hit first before talking to downstream services — some Gateway.

What can we hand off to the Gateway?

Routing
Public-facing services have IPs which are prone to change. The Gateway provides stable routes, discovers service IPs and forwards requests to the right targets.

Protocol translation
Services do not need to support any protocol. Teams pick the most appropriate one, and the Gateway translates requests and responses as needed.

Authentication and tiered access
Domain services should not parse tokens or know about subscription tiers. The Gateway validates credentials, checks access levels, and can short-circuit unauthorized requests before they reach downstream services.

TLS termination
If traffic enters through a single point, TLS can be terminated at the Gateway. Internal services may communicate over simpler internal channels (though in high-security environments, end-to-end encryption may still be required).

Request logging and monitoring
As the Gateway handles all requests, it can centrally log user activity and provide metrics.

Request throttling
The Gateway can track whether a client puts excessive load on the system and stop propagation of frequent requests. And as it sees authentication context and system-wide traffic patterns, it can enforce global rate-limiting strategies — individual services cannot do that effectively.

In short, the Gateway provides a stable application programming interface to an unstable internal world — it is the API Gateway. It hides topology, enforces global policies, and lets domain services focus on business logic. That is why it became a foundational pattern in microservice architecture.