What belongs at the front door
- TLS, JWT checks and scopes
- Rate limits, quotas and body-size caps
- Routing by path and version
- Access logs and trace IDs
Strip, then set, the identity headers
The gateway verifies the JWT, deletes any X-User-Id the client sent and writes its own. Services trust it only because nothing else can reach them.
Put the coupon check in the gateway?
Bad: A god gateway
Business rules, reshaping and sessions pile up; every change queues.
Good: Policy only
The same for every service. Logic stays in services or a BFF.
Cheapest rejection first
TLS, IP and size checks cost microseconds, and cached JWT keys need no network call. Only the rate-limit step leaves the box before the upstream call.
50%
of requests get 429 after 0.5 s
50,000 taps in 10 s is 5,000 RPS against AWS’s 2,500 RPS refill in Hyderabad. The 1,250-request burst empties in half a second. Raise the limit before launch.
Budgets shrink as you go inward
The client waits longest, then the gateway, the service and each dependency. Inverted, the user sees a 504 at 3 s while the charge commits at 6 s.
N + 1 instances across three zones. Can they all fail at once?
The trap
Yes, if every instance loads the same bad config. Ship config like code: validate, roll out by region, keep a last-known-good.
Say it like this
Behind the load balancer, a stateless gateway terminates TLS, checks the JWT, enforces per-key limits and routes. Business logic stays in services, and config ships like code.