One hostname, many services
An API gateway is the one hostname your clients talk to.
A request arrives, the gateway looks at the path or the headers, and forwards it to the right backend. Anything under /users to the user service, anything under /orders to the order service.
Notice what your clients never learn: that twenty services exist at all. Split the order service in two next quarter, or move it to another cluster, and no mobile app needs an update.
Remember how long a mobile release cycle really is and that stops sounding minor. A hardcoded service hostname inside an app lives for years, because some people never update.
Get one stable public contract out of it, with freedom to reorganise everything behind that contract. It is the same reason DNS exists, applied one layer up.
Concentrate the ugly edge-of-network work here too. TLS ends at the gateway, so your internal services never handle certificates for public traffic. Request logging happens once. Malformed requests and unknown paths die here instead of eating backend capacity.
What it costs
State the cost plainly, because it is real. Your gateway now sits on the critical path of every request, adding a hop of a few milliseconds and a place to fail.
Run it highly available, several instances behind a balancer, and watch its latency and error rate more closely than almost anything else you operate.
Guard against the other standing risk: scope creep. Gateways attract business logic the way kitchens attract clutter, and a gateway that knows your order validation rules is a monolith in a proxy costume. Keep it thin: route, authenticate, throttle, transform. Decisions belong in services.
Worked example
Dana's team at a logistics startup has three services and two more coming, with the Android app calling each service's ALB hostname directly. When they rename the tracking service, an old app version keeps calling the dead hostname for months, generating support tickets from drivers on ancient phones. The fix is Kong in front of everything: the app now calls api.fleetly.com exclusively, and a routing table maps /track/* and /dispatch/* to whatever backend currently serves them. Measured overhead is 3 ms at p50. Six months later they split dispatch into two services over a weekend, change two routing rules, and ship zero app updates. The old hostname problem becomes structurally impossible, which is worth more than the 3 ms cost.