The API gateway decision — whether to build custom routing and middleware infrastructure or to adopt a commercial or open-source gateway product — is one of the more consequential infrastructure choices an API team makes, and it is frequently made at the wrong time with the wrong information.

The wrong time is too early: a team of three engineers building an API with one consumer has different infrastructure requirements than a team of thirty engineers building an API platform with hundreds of consumers. The wrong information is a product comparison done without a realistic understanding of the operational overhead that gateway products introduce regardless of their feature set.

Rate limiting is one of the few API design decisions where the failure mode is existential rather than merely inconvenient. An API without rate limiting is an API that can be brought down by a single misbehaving consumer, whether that consumer is a customer with a buggy retry loop, a competitor running a data extraction operation, or an attacker attempting a denial of service. The argument for implementing rate limiting is not about fairness or monetization tiers, though it serves both. It is about operational survival.