Api Gateway medium
Why is 'Statelessness' a mandatory architectural requirement for an API Gateway to scale horizontally during a traffic surge?
- A Because stateful servers are prohibited by the HTTP/2 specification.
- B It ensures that any and every Gateway instance can handle any incoming request, allowing for simple round-robin load balancing and instant auto-scaling.
- C It allows the Gateway to run on cheaper servers that don't have hard drives.
- D Stateless Gateways can cache data directly in the user's browser, bypassing the server entirely.
Answer: B. It ensures that any and every Gateway instance can handle any incoming request, allowing for simple round-robin load balancing and instant auto-scaling.
If a Gateway instance stores local session data, it becomes 'Sticky'. If that instance crashes or suffers from high load, you can't easily move its users to a new server without breaking their 'session'. Statelessness (e.g., using JWTs) allows the system to treat every Gateway instance as a fungible commodity that can be spun up or down instantly.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- Your Gateway communicates with backends via HTTP/1.1 connections. A slow backend service causes 'Head-of-Line Blocking'. How does switching to HTTP/2 as the Gateway-to-Backend transport mitigate this?
- What is the primary architectural role of an API Gateway in a microservices environment?
- Why is 'Stateless Token Validation' (e.g., using JWTs) significantly more scalable at the Gateway level than 'Stateful Validation' (e.g., using Opaque/Reference Tokens)?
- Your Gateway is configured to cache any URL ending in `.css` or `.jpg`. An attacker tricks a victim into visiting `https://api.com/v1/profile/info/style.css`. How can this lead to an 'Account Takeover'?
- An API is receiving a sudden surge of 10,000 requests per second from a single IP address. How does an API Gateway preserve the stability of the backend services?
- How can an API Gateway help prevent 'Double Charging' in a payment system when a mobile client retries a failed request due to a poor connection?