An interactive study companion for Martin Kleppmann's classic on reliable, scalable, and maintainable systems.
Clients must find the right partition for each request — via routing tier, gateway, or aware clients.
Given a key, which node owns it? A routing layer answers this question. Centralized gateways are simple but can bottleneck. Smart clients avoid the hop but must handle map updates.
MongoDB mongos routers sit between apps and shards, caching the chunk map from the config servers. Kafka clients fetch partition leadership metadata from the broker controller. In Kubernetes, an nginx or Envoy ingress acts as a reverse proxy — routing HTTP/gRPC to the right pod. AWS ALB does the same at the cloud edge, with health checks and cross-AZ failover.
Timeline and user-data requests route through a gateway that caches the partition map. When a shard rebalances, the routing tier updates so clients always hit the node that owns a given user_id.
// Twitter/X routing — gateway caches partition map, forwards by key
function routeRequest(userId: string, partitionMap: Map<number, string>) {
const partition = hashPartition(userId, partitionMap.size);
const host = partitionMap.get(partition)!;
return proxy.forward(host, { userId }); // mongos / Envoy style
}