API Gateway Pattern

Why This Matters

You've got a mobile app that needs user info, order history, inventory status, and payment details. In a monolith, one database handles it all. But in microservices, each of these lives in a separate service, often on a different server.

Your options:

1. Make 4+ separate API calls from your mobile app. Slow, and now your client code knows about every internal service.
2. Have one service aggregate the data from the others. But which one? And now services depend on each other.
3. Build a single entry point that clients talk to. Everything else is hidden inside.

Option 3 is the API Gateway.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Step 1 — An API Gateway becomes the single entry point for all clients

1 / 10.5×1×2×3×Playground

Two clients and a single gateway entry point

What It Does

An API Gateway sits between your clients and your microservices. Clients make requests to the gateway; the gateway routes them to the right services, collects responses, and sends back a single answer.

On the surface, this sounds simple. But gateways also handle:

Routing — Map /api/orders to the Orders Service, /api/users to the Users Service.

Authentication — Check JWT tokens once, at the front door. If it's invalid, reject the request immediately. Your internal services don't waste time on auth. They just assume the request is legitimate.

Rate Limiting — If one user makes 10,000 requests in a minute, the gateway catches it and rejects the rest. Protects the whole system from abuse.

Data Aggregation — A client needs both a user's profile and their recent orders. The gateway calls both services in parallel, stitches the responses together, and returns one JSON blob. Client makes one request instead of two.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Step 2 — The gateway routes each request to the correct microservice

1 / 10.5×1×2×3×Playground

Gateway routing requests to the right microservice

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Step 3 — Each microservice owns its own isolated database (database-per-service pattern)

1 / 10.5×1×2×3×Playground

Complete architecture — each service owns its own database

The Real-World Pressure

Imagine you're building Netflix's TV app. The home screen needs your profile, your recommendations, your continue-watching list, and imagery. That's data from at least three different services.

If your mobile app called each service directly, you'd have three separate network round-trips. The home screen would load in 2-3 seconds instead of 500ms. Users would bounce.

Netflix's API Gateway (built with their open-source tool, Zuul) solves this: the TV app makes one call to the gateway, which fans out requests to ProfileService, RecommendationService, and CatalogService in parallel, aggregates everything, and sends it back. One fast response.

The Tradeoffs

Everything has a cost.

Single Point of Failure — If your gateway crashes, the entire system is down. Every client gets an error, even if your microservices are running fine.

Bottleneck Risk — All traffic flows through one place. If it's not properly scaled and optimized, the gateway becomes the slowest part of your system.

Scope Creep — It's tempting to put "just this one piece of business logic" in the gateway. Then another. Then another. Six months later, your gateway is doing authentication, authorization, user enrichment, invoice generation, and fifteen other things. It's become a monolith again, just with a different name.

The gateway works best when it stays lean: routing, auth checks, rate limiting, and light data aggregation. Everything else lives in services.