beginnerintermediateadvanced

System Design · Client-Server and API Gateways

Client-Server and API Gateways

The layers between a client and the code that runs, and what belongs at the gateway

Client → LB → gateway → servicefour distinct jobs
One front doorauth, routing, rate limits
AggregationN backend calls, one client response
No business logicgateway routes, services decide

1.Client-server topology

A request from a browser or mobile app rarely hits a backend service directly. It usually passes through a load balancer, then a reverse proxy or API gateway, before reaching the service that actually handles it — each layer has a distinct job.

Key features

Client: browser or mobile app — initiates requests, renders responses
Load balancer: distributes incoming connections across many backend instances
Reverse proxy: sits in front of one or more services, forwarding requests on their behalf
API gateway: a reverse proxy specialized for APIs — routing, auth, rate limiting in one place
Backend service: the process that actually executes business logic

Who sits between the client and the code that runs

Who sits between the client and the code that runs
Component	Sees	Typical job
Client	The user	Sends requests, renders the response
Load balancer	Every incoming connection	Picks which backend instance handles it
API gateway	Every API call	Auth, routing, rate limiting, one entry point
Reverse proxy	Requests for one or more services	Forwards, may cache or terminate TLS
Backend service	One request at a time	Runs the actual business logic

One request, every layer it passes through

Client

browser or mobile app

Load balancer

picks a healthy instance

API gateway

auth, routing, rate limit

Backend service

runs the business logic

Command

text

client → load balancer → API gateway → backend service(s)
                              ↳ reverse proxy in front of any of them

A request usually passes through a load balancer, an API gateway (or reverse proxy), and only then a backend service instance — four distinct jobs, not one box.

2.API gateway responsibilities

An API gateway is the single front door for a set of backend services. It can handle routing, authentication, rate limiting, request/response transformation, aggregating multiple backend calls into one response, and observability — so every backend service does not reimplement the same cross-cutting concerns.

Key features

Routing: sends a request to the correct backend service based on path, host or header
Authentication: verifies who is calling before any backend service sees the request
Rate limiting: caps how many requests a client can make in a window
Request/response transformation: reshapes a request or response between client and backend formats
Aggregation: combines calls to multiple backend services into one client-facing response
Observability: a single place to log, trace and measure every API call

What an API gateway can centralize

What an API gateway can centralize
Responsibility	Without a gateway	With a gateway
Auth	Every service re-checks tokens	Checked once, at the edge
Rate limiting	Each service tracks its own limits	One shared limiter per client/key
Routing	Client must know every service address	Client calls one host; gateway routes
Aggregation	Client makes N calls, N round trips	Gateway makes N calls, client makes 1
Observability	Logs scattered across N services	One place to see every call in/out

One gateway call, aggregated from three services

Web

Mobile

API gateway

auth, rate limit, route, aggregate

user-service

profile

orders-service

recent orders

billing-service

account balance

Command

text

client → [API gateway: auth, rate limit, route,
                      transform, aggregate, log]
                → backend service(s)

A gateway can own routing, auth, rate limiting, transformation, aggregation and observability — but never the business logic itself.

3.Do not overload the gateway with business logic

An API gateway can own routing, auth, rate limiting, transformation, aggregation and observability — but the moment it starts encoding an actual business rule ("reject orders over the customer's credit limit"), it has become a second, hidden application every backend service now silently depends on.

Key features

Business logic: any rule specific to what a domain entity is allowed to do (credit limits, order rules, pricing)
A gateway rule that references domain concepts (order total, credit limit, inventory count) is business logic, not routing
Business logic in the gateway means every backend service now has an invisible dependency on gateway behavior
Testing, deploying or reasoning about that rule now requires understanding the gateway, not just the owning service
The fix is always the same: push the rule down into the service that owns the entity it is about

The line the gateway must not cross

A gateway may own this

Route a path to the service that owns it
Authenticate the caller and terminate TLS
Rate-limit, retry, and shed load
Transform and aggregate responses
Log, trace, and emit metrics
None of these needs to know what an order is

A gateway may not own this

Any rule about what a domain entity is allowed to do
Anything that reads an order total, a credit limit, an inventory count
A check the owning service cannot see, test, or deploy with
The test: if the rule names a domain concept, it is business logic

Command

text

gateway may:      route, authenticate, rate-limit,
                  transform, aggregate, log
gateway may not:  decide anything about what a domain
                  entity (order, account, inventory) is
                  allowed to do

A gateway can own routing, auth, rate limiting, transformation, aggregation and observability — never a rule about what a domain entity is allowed to do. That belongs in the service that owns the entity.

Spotted a mistake on this page? Tell us.

Read Sheet