API Gateway Platform

Topology Notes

• ·Hot path per request (< 1ms budget): inbound request → API key extraction → Redis HGET to validate API key and fetch tenant_id (< 0.3ms) → Redis Lua rate limit check against sliding window counter (< 0.2ms) → local cache lookup for routing rule (< 0.05ms) → upstream proxy. All three Redis operations must be pipelined or batched where possible to minimize round trips. A Redis cluster round trip budget is approximately 0.1–0.3ms on co-located infrastructure.
• ·PostgreSQL stores the authoritative configuration (tenant definitions, API products, rate limit plans, API key hashes, subscription state). This data is never accessed on the hot path. It is accessed on configuration change events (tenant management API) and during gateway startup (bulk configuration prefetch). PostgreSQL must not be in the critical path for any end-user API request.
• ·Redis key structure for rate limiting: rate:{tenant_id}:{api_product_id}:{window_bucket} where window_bucket is the floor of current_unix_ts / window_size_seconds. Each key has TTL = window_size * 2 to allow sliding window lookups against the previous window. Key expiry is managed by Redis TTL: no explicit cleanup is required.
• ·Kafka usage_events topic receives one message per API request (or batched per gateway replica per second for high-volume tenants). Topic is partitioned by tenant_id to maintain per-tenant ordering for billing consumers. Retention is 7 days to allow billing reprocessing on consumer failures. The billing consumer is a separate service from the gateway and must not be on the gateway hot path.
• ·Configuration invalidation flow: tenant management API writes to PostgreSQL and publishes a config_changed:{tenant_id} message to a Redis pub/sub channel. All gateway replicas subscribe to this channel and evict the affected tenant's local cache entries on receipt. This bounds configuration propagation to sub-second without requiring a gateway restart or coordinated deployment.