API Gateway Platform

Summary

A multi-tenant API gateway providing authentication, distributed rate limiting, request routing, payload transformation, and per-tenant usage analytics for API publishers. The hot path: authentication check, rate limit evaluation, and routing decision: must complete in under 1ms using Redis-only data structures to avoid proxying latency dominating upstream service response time. PostgreSQL stores tenant configuration, subscription plans, and API key definitions. Kafka receives API usage events for downstream billing and analytics. Configuration changes (rate limit updates, routing rule edits) must propagate to all gateway replicas without restart.

Problem Statement

An API gateway sits in the critical path of every request from every API consumer of every tenant. At 100,000 requests per second, a 1ms added latency in the gateway hot path is 100 CPU-seconds per second of added overhead downstream. Redis atomic operations (INCR, Lua scripts for sliding window rate limiting) deliver sub-millisecond rate limit decisions; PostgreSQL configuration lookups on the hot path would be an order of magnitude slower and would create a configuration database bottleneck. The challenge is keeping Redis rate limit state consistent across N gateway replicas under concurrent increment operations, while ensuring that configuration changes published by one gateway replica are visible to all others without a restart or cache invalidation storm. A tenant that misconfigures their rate limit to 0 must not cause all their consumers to fail silently: misconfiguration must be caught at write time, not at request time.