Design and Architecture of Uber’s Self‑Service API Gateway

API gateways have become essential in modern microservice architectures, and Uber’s gateway serves as a unified entry point for all its applications, handling routing, protocol translation, rate limiting, load shedding, header enrichment, security auditing, and more.

The gateway is built as a stack of components that process each request: a protocol manager that deserializes/serializes various payload formats (JSON, Thrift, Protobuf), a middleware layer for cross‑cutting concerns (authentication, authorization, rate limiting, etc.), an endpoint handler that validates and transforms requests, and a client that forwards calls to backend services.

All component behavior is driven by configuration rather than code changes. Engineers edit YAML and Thrift files (stored in a Git‑backed repository) to define protocols, middleware chains, handler mappings, and client settings. The UI converts these configurations into functional APIs and even generates client SDKs.

The configuration files are rich: the protocol manager’s YAML specifies protocol type and Thrift file paths; middleware YAML defines required parameters and transformation logic; handler YAML maps request fields to backend client calls; client YAML pairs with Thrift definitions for services such as TChannel‑based backends.

Uber’s gateway supports two deployment models: a dynamic configuration‑driven model (similar to Kong, Tyk, Envoy) and a code‑generation model that produces a runnable artifact. Uber chooses the latter, using the Zanzibar OSS library to generate Go code from Thrift and protoc, handling custom serialization for i64, enums, and multiple protocols.

Key features unlocked by the gateway include audit logging, authentication/authorization middleware, circuit breakers, fine‑grained rate limiting, automatic documentation generation, mobile client code generation, response field pruning, data‑center affinity routing, and short‑term user bans.

The development team faced several challenges: selecting Go and Java over Node.js for performance and language consistency, handling mismatched data types across JSON and Thrift, managing dynamic versus static configuration storage, building a UI that supports bulk edits, and dealing with payload deserialization requirements for advanced features.

Overall, the article demonstrates how a highly configurable, code‑generated API gateway can provide robust, extensible functionality for large‑scale services, and points readers to the open‑source Zanzibar project for further exploration.