The Capstone Movement: Four Designs That Use the Whole Map

A principle you cannot spend is trivia.

Learning Maps spent twenty-one episodes building one room at a time. The forced choice. The dial. The shard. The cache. The vote. The keyring. The ballroom. Each room taught a single durable idea and hung the rented AWS label on it as a sticker you can peel off when the vendor rebrands. The Blueprint closed that arc.

These four films spend it. Each one designs a real system end to end, the kind you get asked to whiteboard in an interview, and every move gets stamped with a numbered coin naming the room it came from. Nothing new is invented. The whole point is that nothing new is needed. What separates a senior engineer from a clever one is not more invention. It is more recall.

Four systems, four different axes. Where the data lives. When the work happens. What shape the data is in. And the day the rule breaks.

Capstone 1. Designing a URL Shortener

Watch on YouTube (8:49).

Make long links short. That is the entire product. You could sketch it on a napkin in ten seconds. Two columns, the long link and the short code, look one up and send the reader along. This exact toy is the first question asked in system design interviews the world over, because the napkin version works beautifully for ten users and detonates at ten billion. The gap between those two numbers is the whole craft.

Listen to the shape before you pick anything. No joins. No reports. Just an enormous pile of tiny key to value reads and a trickle of writes, maybe a thousand reads for every write. That shape chooses the architecture for you. A key value store leaning toward availability, because a fresh link showing up a second late is fine. A cache in front, because the same popular links get clicked over and over, which is the cache bet at its best. A stateless redirect tier behind a load balancer, spanning more than one zone, because a dead shortener does not break one page, it breaks every link anyone ever made.

Then the one genuinely hard decision, and the interview lives inside it. How do you mint the short code? Hashing the long link is the trap, because hashes collide and you have quietly overwritten somebody's link. The clean answer is almost boring. Keep an ever increasing counter and write the number in base sixty-two, the digits plus upper and lower case letters, which turns a billion into five or six characters. A counter never repeats, so codes never collide. But a single global counter is a single point of failure and a bottleneck, so you hand each server a pre-allocated block of numbers and let it issue codes from its own block. No collisions. No bottleneck. No coordination on the hot path.

Capstone 2. Designing a Social Newsfeed

Watch on YouTube (8:11).

Show me the latest posts from everyone I follow, newest first. It sounds like one database query. It is quietly the most expensive sentence in consumer software, and it is the reason every social network eventually builds the same strange machine.

The shortener was all reads. This one is a war between reads and writes, and choosing where to fight it is the design. The essential question is when you build a feed. Build it on write and you shove each new post into every follower's feed the moment it lands, so reads are instant because the feed is already assembled. Build it on read and posting is cheap but opening the app is expensive, because you gather from everyone you follow and merge it live every single time.

Then the trap springs. Follower counts are wildly uneven. Most people have a few hundred. A tiny handful have a hundred million. Under fan-out on write, one celebrity post becomes a hundred million writes, a tidal wave that backs up every queue and melts the system. Flip everyone to fan-out on read to dodge it and you have made the common case slow to protect the rare one. The answer the whole industry lands on is neither. It is both. Push for normal accounts, pull for the handful of celebrities, merged in when a follower opens the app. You match the strategy to the shape of the account, which is the same classify then match move as pricing the spike differently from the baseline.

Capstone 3. Designing a Game Leaderboard

Watch on YouTube (6:35).

Fifty million players, one scoreboard. Show me the top ten, and show me my own rank, this instant, the moment my score changes. It sounds trivial until you ask the one innocent question. What, exactly, is a rank?

Store the scores in an ordinary table and rank means count every player with a higher score. That is a full scan of fifty million rows for one number, millions of times a second. The naive store makes the read impossible. And no amount of caching or scaling will ever rescue a structure that forces a scan.

So the move is not where to put the data. It is picking a structure that already knows the order. A sorted set, every player kept in score order at all times, maintained on each write. Now the costs collapse. Updating is cheap. Top ten is read the first ten. Rank is a near-instant lookup. Keep it in memory as a live read model, fed by a stream of score events, with the durable scores in a normal database behind it.

The lesson is the smallest and the sharpest in the series. Sometimes the bottleneck is not scale, it is shape. There was no clever algorithm here. The right data structure did not optimize the query. It deleted it.

Capstone 4. Designing a Chat Application

Watch on YouTube (7:27).

Send a message, and it appears on your friend's screen now. Not when they refresh. Not in ten seconds. Now.

That one word demolishes the architecture the series leaned on for ten lessons. Every system so far was request and reply. You ask, it answers. Chat needs the server to reach out to you, unprompted, which means a live line held open between you and one specific machine. And the moment a server remembers you, our beautiful interchangeable workers are not interchangeable. A is on server one. B is on server seven. The server holding A has no idea how to reach B.

You cannot externalize a socket. A live wire physically lives on one machine, and there is no shared filing room for an open connection. So you stop pretending. Quarantine the state to a thin gateway tier of connection servers, and keep it thin. Put a fast in-memory registry in front of it that knows which server holds each line. Store the message durably first so history and order survive, then route it across the fleet on a pub-sub backplane, which is fan-out turned inward. If the recipient is offline there is no line to push to, so the message waits in a queue until they reconnect. Presence rides on heartbeat timers. Delivery retries, so you dedup.

We did not defeat statefulness. We contained it, and kept everything else stateless behind it. Knowing the rule is competence. Knowing exactly when to break it is the other thing.

What the movement adds up to

Read the four together and a pattern surfaces that no single room could teach.

Every one of these designs turned on a question asked before any technology was named. What shape is this workload. When does the work have to happen. What does the hottest query actually cost. Answer that honestly and the architecture mostly falls out. Answer it late and you spend the rest of the project scaling your way out of a decision you never made on purpose.

The second pattern is that the hard part is never the part that looks hard. Not the storage, not the traffic. It was minting a code without collisions. It was one account with a hundred million followers. It was the definition of the word rank. It was the word now. In each case the system was easy and one detail was load bearing, and the design is really the act of finding which detail that is.

And the third is the reason the coins are on screen at all. Four systems that have nothing to do with each other were built almost entirely out of the same twenty-one rooms. The cache bet shows up in three of them. Availability over consistency shows up in all four. Fan-out solves a feed and then, turned inward, routes a chat message. That is what the map was for.

Where the map goes next

The principles arc is complete and the first four designs are on the board. Next is the video pipeline, the exact opposite of chat: work too heavy and too slow to ever make you wait for it. Then a hotel reservation, a web crawler, and a stock-exchange finale.

All twenty-five films are on the Learning Maps hub, grouped by wing. They are audio-first and built to survive partial attention, so they work on a walk with your eyes closed. The napkin map rewards watching without ever requiring it.

License

These films are licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix them, repost them, drop them into your own thing. Credit Napkin Films / Organic Arts LLC and link CC BY 4.0. The engine code, Napkin Films and ChipForge, is GPL-3.0-or-later. ElevenLabs voice audio is licensed content and is not redistributed. URL shorteners, key value stores, base sixty-two encoding, distributed counters, fan-out on write and on read, pub-sub, message queues, sorted sets, in-memory read models, WebSockets, connection registries, presence, and idempotent delivery are standard system design concepts. No copyrighted material was sampled.