API Gateway
API Gateway
What is an API gateway?
- The 'front door' every request passes through
- Authentication, routing, and limits in one place
- In front of microservices
Putting an API gateway up front cuts the number of addresses a client has to remember down to one. A mobile app no longer needs to hold separate domains for the order, inventory, and settlement services, and even if you split services or move servers internally, you no longer have to redeploy the app and wait for store review. What changes is not the number of calls but how far a change can ripple outward. It is most accurate to think of it as a mechanism that separates your internal structure from the interface you have promised to the outside.
Drawing boundaries against look-alike components makes design easier. A load balancer focuses on spreading traffic evenly across multiple instances of the same service, a service mesh handles internal communication between services, and a gateway takes care of north-south traffic coming in from outside. The settings are fairly concrete, too. Limits are split by issued key, such as 60 calls per minute for a partner key and 600 per minute for an internal admin tool; response timeouts are usually set at 3–10 seconds; and the latency added by one extra hop is on the order of a few to a few dozen milliseconds. If you need to assemble a different response shape for each type of client, that is the job of a BFF (Backend For Frontend), not the gateway.
The point where things most often go wrong in practice is business logic piling up in the gateway. Once teams start adding discount calculations or member-tier branching because “it’s convenient to handle it all here,” the gateway turns into a new single point of failure where every service stops together whichever team deploys. It is also common to postpone redundancy, then have one gateway instance die and take ten perfectly healthy services down with it. Thinking that internal services can be left unprotected because authentication was done at the front door is equally dangerous. Once the internal network is breached, every service is exposed, so internal services should keep at least minimal token validation.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
Ilyoung JungExpert in smart factories, equipment management, and Industry 4.0As microservice architectures spread, putting a single entry point in front of multiple services became a standard pattern.
Let’s look at a hypothetical case. Company A, an online food distributor with 320 employees, had an architecture where its own app, its website, and six partner malls each called 11 internal services directly. Because the authentication code differed slightly from client to client, changing a single line of the token expiry policy took two weeks, and a surge of inventory lookups from one partner mall once froze even the order service for 12 minutes.
- When the platform team lead pulled three weeks of call logs, 41% of all requests were inventory lookups, and half of those came from a single partner mall. “The problem is that there’s no place to block it at all,” someone said in the meeting.
- They set up a managed gateway as the front door and moved the partner-mall APIs first. The backend manager chose a phased migration, shifting traffic 10% → 50% → 100% while keeping the old domain open for three months.
- They consolidated token validation in the gateway and set a limit of 60 calls per minute per partner key. Excess requests were returned with a 429, and the retry interval was included in the response header to guide partner developers.
- Someone proposed calculating tier-based discounts in the gateway too, but the CTO rejected it, holding that business logic stays in each service. The gateway would handle only four things: authentication, routing, rate limiting, and logging.
- They made the gateway redundant across two availability zones, with 5-second health checks and automatic failover. The infrastructure lead decided to run a drill every quarter that deliberately takes one instance down.
- Six months later, a token policy change that used to take two weeks took half a day, and partner-mall incidents fell from 4 to 0 over the same period. Average response latency rose by 9ms, but the order losses from outages disappeared, so the business teams were on board.