Why an API gateway, not just an ingress

Once you can get an external IP, you need something to route HTTP to the right app and, ideally, to add the cross-cutting concerns every API needs — auth, rate limiting, request shaping. A plain ingress controller (like ingress-nginx) does routing well. An API gateway does routing and gives you a real plugin system for those cross-cutting concerns.

I used Kong (the open-source edition). It plays the role of Kubernetes ingress controller and a full gateway:

• routes by hostname/path to backend services, like any ingress;
• but also offers plugins — authentication, rate limiting, CORS, request/response transforms — attached declaratively to routes via Kubernetes objects.

For a platform meant to demonstrate how production traffic is handled, the gateway model is more interesting and more representative than a bare ingress. It's also a single, consistent place to reason about "what happens to a request before it reaches my app."

Why we use this: an ingress answers "where does this request go?" A gateway also answers "what should happen to it on the way?" — and in real systems, a lot needs to happen on the way. Learning the gateway model is more transferable.