System‑design primers drop

Three interview topics landed at once because they all ask the same question in different clothes: where do you keep state when the system gets big. A video platform keeps state in files and caches, an auth system keeps state in tokens and revocation lists, and a tracking app keeps state in open connections or repeated requests. (rfc-editor.org, cloud.google.com, ably.com) Start with video. A YouTube-sized system does not stream one giant movie file from one central server, because a single high-bitrate file is too slow to seek through and too expensive to ship across oceans on every request. (cloud.google.com, medium.com) The usual trick is to chop one upload into many smaller chunks and many quality levels, so a phone on weak hotel Wi‑Fi can fetch a lower-bitrate segment while a television on fiber can fetch a sharper one. That is adaptive streaming, and it turns one video into a ladder of trade-offs between storage cost and playback smoothness. (cloud.google.com, vdocipher.com) That choice creates a second bill. Storing several encoded versions of the same 10-minute clip multiplies bytes on disk, but it cuts buffering and makes fast scrubbing possible because the player can jump to a nearby segment instead of rereading the whole file. (medium.com, markaicode.com) Then comes delivery. A content delivery network is a chain of edge caches near users, and it reduces round-trip distance so the origin does not melt when millions of people press play on the same clip. (cloud.google.com, vdocipher.com) Now switch to login. A JSON Web Token is a signed bundle of claims carried by the client, which means each service can verify the signature locally instead of asking a central session store on every request. (rfc-editor.org) That speed creates the breach problem. If a token is stolen at 9:00 a.m. and it stays valid until noon, every server that trusts the signature will keep accepting it unless you add some new source of state outside the token itself. (rfc-editor.org, appliscale.io) Teams usually pick one of three escapes. They shorten access-token lifetime to a few minutes, keep a server-side denylist keyed by token identifier, or rotate signing keys and invalidate every token signed with the old key. (rfc-editor.org, oauth.net, toolshelf.tech) Each escape gives something up. Short lifetimes push more traffic into refresh flows, denylists reintroduce a database lookup that stateless tokens were supposed to avoid, and key rotation is a fire alarm that logs out good users along with bad ones. (appliscale.io, toolshelf.tech) The GPS primer is the same argument over a different wire. Polling means the phone asks “where is the driver now” every few seconds, while WebSocket means one long-lived connection stays open so the server can push updates the moment coordinates change. (ably.com, websocket.org) Polling is simpler because every request stands alone and ordinary load balancers already know how to handle it, but a 5-second poll interval turns 100,000 riders into 20,000 requests per second even when nothing moved. (ably.com, getstream.io) WebSocket cuts that request churn and lowers latency, but it moves the pain into connection management because each open socket consumes memory, needs heartbeat handling, and often needs sticky routing or shared connection state when you scale across many servers. (websocket.org, ably.com) That is why these primers are catnip for interviews. The right answer is rarely “use object storage,” “use JSON Web Tokens,” or “use WebSocket,” and is usually “pick the failure you can afford, then add just enough state back in to control it.” (geeksforgeeks.org, rfc-editor.org, cloud.google.com)