API Gateway Decisions: Rate Limiting, Auth, and Routing at Scale

Most API Gateway decisions look simple in early-stage SaaS systems.

Until traffic and integrations start growing.

We faced this while scaling a Rails-based platform with multiple client apps and third-party integrations.

Initially, routing everything directly to services worked fine.

Then gradually:
* Auth logic started getting duplicated
* Rate limiting became inconsistent
* Some APIs were overloaded by a few heavy clients
* Routing rules became difficult to manage across environments

Nothing failed suddenly.
But operational behaviour became unpredictable.

That’s when we introduced a proper API Gateway layer.

Not just for routing.

But to centralize:
* Authentication
* Request limits
* Request validation
* Traffic control

One interesting observation:
After applying request limits properly, a single noisy integration that was consuming ~35% of API traffic stopped affecting other customers entirely.

Support tickets around API latency dropped noticeably after that.

The important learning:
At scale, API Gateway is not just an infrastructure component.
It becomes a control layer for system behaviour.

Without clear boundaries, traffic patterns from one client can quietly impact the entire platform.