The API Gateway
Adda's monolith is now a dozen services, and every one of them re-checks the auth token. Nabila's first week: build the single front door that does routing, auth, and rate limits once.
The problem
Adda split its monolith into a dozen services, and the mobile team — the friend who built that tiny client back in Part 1, now a whole squad — asks a fair question: which URL do they call? There's a Users service, a Posts service, a Feed service, each on its own host and port, each scaling up and down and moving around.
Worse, every one of those services has to check the auth token, enforce rate limits, log the request, and terminate TLS. Adda has copied the same security-critical boilerplate into a dozen codebases. Fix a token-validation bug and you're shipping the same patch twelve times, hoping nobody forgot one. This is the week Nabila joins Adda as its first platform and security engineer — and she takes one look at twelve copies of the auth check and says, "this belongs in exactly one place."
A first attempt
Just expose every service directly and let clients call them. Publish a list of hostnames, hand it to the mobile and web teams, and you're done.
It falls apart fast. Clients are now hard-wired to Adda's internal topology — split a service in two and every app must ship an update. Each client makes 6 round trips to render one screen. Every service re-implements auth, and each is a public attack surface — the exact thing Nabila was hired to shrink. And you can't change an internal address without breaking someone. The naive approach turns Adda's service map into part of its public API contract, which is the last thing you want to freeze.
The insight
Put one component in front of everything. Clients talk to it; it talks to the services.
That single front door is the API gateway. Because every request flows through it, it's the natural place to do the work that every request needs — authentication, rate limiting, TLS termination, logging — exactly once. Services behind it get to be simple, trust their caller, and stay private on Adda's internal network.
One place for cross-cutting concerns
A gateway centralizes the work that has nothing to do with business logic: auth, rate limits, TLS, routing, logging. Adda's services stop re-implementing it, and Nabila changes policy in one place instead of twelve.
How it works
Terminate and authenticate
The gateway ends the client's TLS connection, then validates the auth token once. If it's
invalid, the request is rejected here — it never reaches a service. Valid requests get the
verified user identity attached (say, an X-User-Id header) so downstream services don't
re-check.
Enforce policy
Rate limits, quotas, and IP rules run here, before any expensive work happens. One abusive client is stopped at the door, protecting every Adda service at once.
Route to the right service
Based on the path, the gateway forwards to the matching upstream — /posts/* to the Posts
service, /feed/* to Feed — picking a healthy instance behind a load balancer. Clients never
learn the internal addresses.
Optionally aggregate
For Adda's mobile home screen that needs profile, feed, and suggestions, the gateway can fan out to all three, combine the results, and return one response — turning 3 client round trips into 1.
Concrete numbers
A well-tuned gateway adds ~1–3 ms of latency per request — cheap next to the tens of milliseconds of real work behind it. A single gateway node handles tens of thousands of requests per second; Adda runs several behind a load balancer for capacity and redundancy.
The aggregation win is the vivid one. Adda's mobile screen needing 5 resources over a 100 ms mobile round trip costs 500 ms if the client calls each service itself. Move the fan-out to the gateway — where inter-service hops are ~1 ms — and the client pays one 100 ms round trip plus ~5 ms of internal calls. Five sequential trips become one.
When to use it
The gateway is a single point of failure and a bottleneck
Every request flows through it, so if it's down, all of Adda is down, and if it's slow, everything is slow. Nabila runs it as multiple stateless replicas behind a load balancer, keeps its logic thin, and never lets heavy business logic creep in. A gateway that starts orchestrating workflows becomes a new monolith at your front door.
Gateway vs load balancer
They overlap but differ in altitude. A load balancer spreads traffic across identical instances (layer 4/7, "which copy?") — the one Tanvir added in Part 1. A gateway makes application-level decisions — auth, routing by path, aggregation ("which service, and is this caller allowed?"). You typically run a load balancer in front of the gateway, and another behind it per service.
Practice
Recap
- A gateway is the single front door that does the work every request needs — auth, rate limiting, TLS, routing, logging — once, instead of copying it into every service.
- It hides internal topology so Adda can split, move, and rescale services without breaking clients, and it can aggregate calls to cut client round trips.
- It's a single point of failure and a potential bottleneck: keep it thin, stateless, and replicated, and never let business logic move into it.
Monolith vs Microservices
The service sprawl that makes a gateway necessary.
Rate Limiting
The gate the gateway enforces on abusive callers.
Load Balancing
What sits in front of the gateway and behind each service.
In an interview
How to discuss this
Introduce the gateway as the home for cross-cutting concerns, and immediately name the risk: it's a single point of failure, so you run it stateless and replicated. Distinguish it from a plain load balancer (application-level decisions vs "which copy"), and if the design has several client types, mention Backend-for-Frontend as the natural next step. Keep it thin — the moment it holds business logic, you've rebuilt a monolith.
How is this guide?
Last updated on
Monolith vs Microservices
Adda has been one codebase since the laptop under Ria's desk. It was a joy — until the team grew and every deploy became terrifying. Splitting into services helps, but hands Adda a distributed-systems bill.
Message Queues
A video attached to an Adda post takes 90 seconds to process — and it's holding the upload request hostage. When Adda goes viral, that one slow task takes down the whole API. A queue absorbs the shock.