SA-301f · Module 2

Gateway Anti-Patterns

3 min read

The API gateway is the most common location for architectural anti-patterns because it is convenient. Every request passes through the gateway, making it tempting to add "just one more" piece of logic. Over time, the gateway accumulates business logic, data transformation, and orchestration — becoming a monolith at the entry point of a microservices architecture. I have seen gateways that contain more business logic than any individual service. The services are micro. The gateway is macro. The architecture is inverted.

Do This

  • Limit the gateway to cross-cutting concerns: authentication, rate limiting, routing, logging, and TLS termination
  • Move business logic to services — the gateway routes requests, it does not process them
  • Monitor gateway latency as a first-class SLI — the gateway adds latency to every request

Avoid This

  • Add data transformation logic to the gateway — transformations belong in the services or in a dedicated BFF layer
  • Orchestrate multi-service calls from the gateway — use a dedicated orchestration service or saga coordinator
  • Cache business data in the gateway — the gateway becomes a stateful component that is difficult to scale and restart