API Gateways, Service Mesh and BFF
Where cross-cutting concerns live once you have more than one service. What belongs in the gateway, what belongs in the mesh, and when a BFF earns its keep.
Covers: Gateway responsibilities, backend-for-frontend, service mesh and sidecars, service discovery, north-south vs east-west
The moment you have several services, the same questions appear in every one: who is this caller, are they allowed, are they over their rate limit, where do I send this, and what happens when the callee is down. An API gateway answers those for traffic entering the system; a service mesh answers them for traffic between services.
North-south and east-west traffic
The gateway handles traffic entering the system; the mesh handles traffic between services. Different problems, different tools.
Flow
- Clients to API gateway
- API gateway to BFF layer
- BFF layer to Service mesh
- Service mesh to Order service
- Service mesh to User service
- Order service to User service(via sidecars)
30-second answer
The gateway owns edge concerns for untrusted external traffic: TLS termination, authentication, rate limiting per API key, request validation, routing and response caching. The mesh owns transport concerns between trusted internal services: mTLS, retries, timeouts, circuit breaking, load balancing and telemetry, implemented as a sidecar so it is uniform across languages. Business logic, authorisation decisions that depend on domain state, and data validation belong in the service - the classic failure is a gateway that accumulates business rules until it becomes an undeployable monolith nobody owns.
| Concern | Gateway | Mesh | Service |
|---|---|---|---|
| TLS termination (external) | ✅ | - | - |
| mTLS between services | - | ✅ | - |
| Authentication (who are you) | ✅ | - | - |
| Authorisation (may you do this to this record) | Coarse only | - | ✅ |
| Rate limiting per client | ✅ | Secondary | - |
| Request/response validation against a schema | ✅ | - | ✅ |
| Retries, timeouts, circuit breaking | For external calls | ✅ | - |
| Load balancing between instances | - | ✅ | - |
| Service discovery | - | ✅ | - |
| Distributed tracing propagation | Starts the trace | ✅ | Adds spans |
| Business rules | ❌ never | ❌ never | ✅ |
Backend for frontend
A BFF is a thin service per client type. The mobile app needs compact payloads and fewer round trips; the web app needs richer data; a partner API needs a stable long-lived contract. Serving all three from one API guarantees over-fetching for someone and a slow, contested change process for everyone.
- Owned by the client team, which is the whole point - they can reshape their own endpoint without negotiating with the service teams.
- Aggregates several backend calls into one client round trip, which matters enormously on mobile networks.
- Contains no business logic - it composes and reshapes. The moment domain rules appear in a BFF you have created a shadow service.
- Costs an extra hop and another deployable per client. With two clients that is usually not worth it; with four or more and diverging needs, it is.
Service discovery
| Approach | How | Trade-off |
|---|---|---|
| DNS | Service name resolves to instance IPs | Simple; TTL caching makes it slow to react to changes |
| Client-side discovery | Client queries a registry and picks an instance | Efficient, no extra hop; logic duplicated in every language |
| Server-side discovery | Client calls a load balancer that knows the instances | Simple clients; the balancer is another hop and another dependency |
| Mesh / sidecar | Sidecar receives endpoints from the control plane | Uniform across languages; needs a mesh |
Say these points
- Gateway = north-south edge concerns; mesh = east-west transport concerns.
- Authenticate at the edge, authorise in the service where the domain state lives.
- A BFF is owned by the client team, aggregates calls, and holds no business logic.
- A mesh pays off above roughly 10–15 services or with multiple languages.
- Never let business rules accumulate in the gateway.
Avoid these mistakes
- Business logic creeping into the gateway until nobody can deploy it.
- Fine-grained authorisation at the edge, duplicating domain rules.
- Adopting a service mesh for four services.
- A BFF per client that quietly becomes a second backend.
- Forgetting the gateway is itself a single point of failure that needs redundancy.
Expect these follow-ups
- How does a request keep its trace context across gateway, BFF and three services?
- How would you rate limit per user when the user ID is inside an encrypted JWT?
- What breaks if the mesh control plane goes down?
Showing 1 of 1 questions for api-gateway-and-service-communication.
Check your understanding
3 questions · no sign-up · misses join your review queue, on this device only