advanced 2 min answer

Your API gateway configuration has grown to 8,000 lines with request transformations and cross-service orchestration. Changes require a platform team ticket and take two weeks. How do you fix this?

api-gatewaycouplingplatformtimeouts
Show the full answer Hide the answer

Name the failure

The gateway has become a distributed monolith — shared, centrally owned, untestable in isolation, and on the critical path of every team's delivery. The two-week lead time is the symptom; coupling is the disease.

It is also the highest-risk component in the estate: everything passes through it, so its availability is the estate's availability and every added feature is another way for it to fail.

The line to draw

Policy belongs in the gateway. Logic does not.

Belongs: TLS termination, authentication and coarse authorisation, rate limiting, compression, request logging and correlation ID injection, protocol translation, routing.

Does not: request enrichment, response composition across services, business rules, per-consumer transformations.

The test: could this change break a business behaviour? If yes, it belongs in a service that has tests and an owning team.

Migrating out

Inventory and classify the existing rules against that line.

Move orchestration into a backend-for-frontend service — one per client type, owned by the team that owns that client. Composition is legitimate; it just needs an owner and a test suite, and BFFs give it both without a shared bottleneck.

Move transformations into the owning services, or into an adapter the service owns.

Move routing configuration into service-owned declarations — routes defined alongside the service and applied by the platform. This alone removes most tickets while keeping central policy enforcement.

Fix the timeouts while you are in there

Gateways in this state almost always have inconsistent timeouts. Timeouts must decrease inward, each layer leaving margin for its own overhead and ideally a retry.

The classic symptom of getting it wrong: the gateway returns 504 while the operation actually completes, so the client is told it failed and retries a non-idempotent operation. Also check the load balancer's idle timeout is not shorter than the gateway's, which cuts responses mid-flight.

Where the platform supports deadline propagation, use it — each hop then knows the remaining budget and can decline work it cannot finish.