An API gateway is a server that sits between clients and backend services, acting as the single entry point through which all API traffic passes. Every request goes through the gateway, which can inspect, modify, authenticate, route, transform, and rate-limit that traffic before it reaches any backend service. For teams running multiple services, an API gateway centralizes concerns that would otherwise be duplicated across every service independently.

Understanding what a gateway provides — and what it does not — is the prerequisite to deciding whether one belongs in your architecture.

API security failures are not exotic. They rarely involve sophisticated attacks on cryptographic primitives or novel zero-day exploits. The most consequential breaches — the ones that expose millions of records, compromise user accounts, or shut down services — happen because an API allowed something it should not have, at a scale its designers did not anticipate. Understanding the fundamental attack surface of an API and designing against it deliberately is the entire discipline. It is not advanced knowledge. It is the baseline.

Rate limiting is one of those features that looks optional until the moment it becomes mandatory. Without it, a single misbehaving client — a misconfigured retry loop, a runaway script, a bad actor — can degrade or take down your API for every other consumer. With it, you define the boundaries of acceptable usage and enforce them automatically. For any API exposed to more than one consumer, rate limiting is infrastructure, not a feature.