In this pattern, we have a single point of entry that exposes a well-defined API, and routes requests to downstream services based on endpoints, routes, methods, and client features.
“As the number of services of a platform grows clients need to interact with more and more services. Because each service might have different endpoints, belong to different teams, and have different release cycles, having the client manage these connections can be challenging.”
The downstream services could be lambda functions, external third-party APIs, Fargate containers, full-blown microservices, and even internal APIs.
API Gateway, App Load Balancer or AppSync can be leveraged to implement it as the routing engine.
Having an abstraction layer between clients and downstream services facilitates incremental updates, rolling releases, and parallel versioning. Downstream services can be owned by different teams, decoupling release cycles, reducing the need for cross-team coordination, and improving API lifecycle and evolvability.
This pattern is also known as the API Gateway or Gateway Router.
The Gateway can be a single point of failure. Managing resources and updating the client-facing interface can be tricky. It could become a cross-team bottleneck if it’s not managed via code automation.