Section 6: Two Doors, One Table - High-Level Architecture

Executive Summary: This section puts the whole system on one whiteboard: an edge layer, two stateless services (a Redirect service for clicks and a Link API service for creates), a range allocator, a sharded Redis cache, a multi-region key-value store, and Kafka carrying click events toward analytics. We trace Maya's create and one of her subscribers' clicks hop by hop. Then we defend the three structural choices: splitting read from write, using a queue only for analytics, and serving redirects active-active across regions. Last, we give a number for each component we left out. The result is about nine boxes, and each one is there because Section 3's arithmetic needed it.

The interviewer slides the marker across the table: "Okay. Draw it." Section 1 called this "two systems wearing one name," and the diagram has to show that. The create path carries about 1,160 writes per second on average. The redirect path carries about 116,000 reads per second. Those two flows share a table and very little else. If your drawing puts both through the same box, the interviewer's next question is already written.

The Whole System on One Whiteboard

Here is what each box does, and what it doesn't do:

• The edge is a bouncer, not a cache. It handles TLS termination, DDoS absorption, and global routing to the nearest healthy region. In v1 it does not cache redirects. The reason is under "The Boxes That Are Not There" below.
• The Redirect service is stateless and read-only. About 10 K rps per instance against a 350 K/s peak gives 35 instances; we run **50 for headroom**. Each one keeps a small in-process LRU (60 s TTL) for the hottest keys.
• The Link API service owns creates, disables, and owner listings. It holds the current ID block in memory and never reads Redis on the create path; its only cache operation is deleting any negative entry for the code it just wrote (Section 7).
• The range allocator is one row in a strongly consistent store. A Link API server takes a block of 1,000,000 IDs with a single atomic increment. Section 8 covers it in depth.
• Redis holds the ~200 M-entry hot set in ~100 GB, spread over 6 shards of 32 GB, each with a replica.
• The KV store is the system of record: Section 5's links table, hash-partitioned on short_code and replicated across regions.
• Kafka carries one ~200-byte event per click. Nothing on the redirect path ever waits for it.