Key Technologies

API Gateway

The single front door to a set of services — routing, auth, rate limiting, TLS and aggregation handled in one place so your services don't each reinvent them.

An API gateway is the single entry point that sits between clients and your backend services. Every request comes in through it, and it handles the cross-cutting concerns — authentication, rate limiting, routing, TLS — before passing the request to the right service. Instead of ten services each implementing auth, you implement it once, at the door.

What it does

  • Routing. Maps a path to a backend: /users/* → the user service, /orders/* → the order service. Clients see one host; the gateway knows where everything lives.
  • Authentication & authorization. Verifies the token/session once, up front, and rejects unauthenticated requests before they reach your services. Services can then trust the identity the gateway passes along.
  • Rate limiting & throttling. Enforces per-client limits centrally, protecting every service behind it from abuse and overload.
  • TLS termination. Handles HTTPS at the edge so internal services can speak plain HTTP on the private network.
  • Request shaping. Response caching, compression, request/response transformation, and sometimes aggregation — fanning one client request out to several services and composing the result (though that often belongs in a dedicated backend-for-frontend).
clients ─► [ API Gateway: auth · rate limit · routing · TLS ] ─► user svc
                                                               ─► order svc
                                                               ─► payment svc

Gateway vs load balancer

They're often confused. A load balancer spreads traffic across identical copies of one service (layer 4/7, "which instance?"). An API gateway routes and applies policy across many different services (layer 7, "which service, and is this request allowed?"). In practice a load balancer usually sits in front of the gateway, and the gateway in front of your services.

Why it matters in a design

In a microservices system, the gateway is what keeps the clients simple and the services focused. Clients talk to one endpoint; services don't each re-implement auth, TLS, and rate limiting. It's also the natural place to add API versioning, observability (every request is logged once), and a kill-switch for a misbehaving client.

What to watch

  • It's a single point of failure — run it redundantly (managed gateways like AWS API Gateway, or an Nginx/Envoy/Kong tier do this for you).
  • Don't put business logic in it. The gateway does cross-cutting concerns; routing and policy, not domain decisions. Logic creeping into the gateway turns it into a fragile monolith.
  • Latency hop. It's one more network hop — cheap, but real; keep it close and fast.

What to say in an interview

Bring it up the moment you have more than one service behind the client:

"Clients hit a single API gateway that terminates TLS, authenticates the request, applies per-user rate limits, and routes to the right service — users, orders, payments. That keeps auth and throttling in one place instead of in every service. It sits behind a load balancer for redundancy, and I'd keep business logic out of it."

Next up: Cassandra — a wide-column store built for massive write volume.