Api Gateway easy
In what scenario is an API Gateway typically considered to be 'unnecessary' or even harmful overhead?
- A Small Monolithic applications where all UI, database, and logic logic reside in a single process on a single server.
- B Large enterprise applications with more than 500 distinct microservices.
- C Applications that need to support both Mobile and Web users simultaneously.
- D Critical financial systems that require high levels of security and audit logging.
Answer: A. Small Monolithic applications where all UI, database, and logic logic reside in a single process on a single server.
API Gateways solve the complexity of 'many backends'. If you only have *one* backend (a monolith), the Gateway just adds unnecessary latency and cost. For a monolith, a simple Load Balancer (like Nginx) is much more appropriate for handling raw traffic.
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?