Api Gateway medium
In the 'Microservices' philosophy, why is it considered an 'Anti-Pattern' to place complex business logic (e.g., calculating tax or loyalty points) inside the API Gateway?
- A Because Gateways are built only with C++ and cannot execute complex mathematical formulas.
- B It creates a 'Thick Gateway' (Monolithic logic at the edge), making the Gateway hard to test, slow to deploy, and a centralized bottleneck for all development teams.
- C It prevents the microservices from being able to access the internet.
- D Business logic in the Gateway forces the frontend to skip authentication.
Answer: B. It creates a 'Thick Gateway' (Monolithic logic at the edge), making the Gateway hard to test, slow to deploy, and a centralized bottleneck for all development teams.
Gateways should be 'Smart Pipes' (Routing, Auth, Security) that talk to 'Dumb Endpoints' (Services that own the business rules). If you put domain logic in the Gateway, you've essentially built a distributed monolith where changes to one service require redeploying the global Gateway.
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?