Two system‑design case studies surfaced
A stateless-auth system design problem that covers revoking hacked JWTs and a storage case focused on handling 500 hours/min of video uploads were posted as FAANG‑level study prompts. Both include visual diagrams and practical tradeoffs useful for interview preparation (System Design Talks 25 - Stateless Auth, System Design Talks 26 - The 3 Musketeers of Storage).
Two new interview case studies on distributed systems were posted this week, one on stateless sign-in and one on video storage at upload scale. (x.com, x.com) The first prompt, labeled “System Design Talks 25 - Stateless Auth,” asks how to keep JSON Web Tokens fast to verify while still cutting off a stolen token before it expires. JSON Web Tokens are signed login passes that let servers check identity without calling a session database on every request. (x.com, owasp.org) The usual fix is to shorten the life of the access token and move longer-lived trust to a refresh token, which can be rotated or revoked when a device is lost or an account is hijacked. The Open Web Application Security Project says a digest of a token can be placed on a denylist until expiration, and Google and Auth0 both document refresh-token revocation and rotation as standard controls. (owasp.org, developers.google.com, auth0.com) The tradeoff is the heart of the exercise: every denylist check adds a state lookup, often in a cache such as Redis, to a design that was chosen to avoid state in the first place. Short-lived access tokens reduce that cost, but they push more traffic onto the refresh path and make race conditions and replay detection part of the design. (owasp.org, auth0.com, auth0.com) The second prompt, “System Design Talks 26 - The 3 Musketeers of Storage,” uses a familiar ingestion number: 500 hours of video uploaded per minute. At that rate, a service is taking in about 30,000 hours every hour and roughly 720,000 hours every day before it even starts transcoding files into multiple playback formats. (x.com, aboutchromebooks.com, docs.cloud.google.com) A storage design at that scale usually splits the job into three parts: durable object storage for the original file, a queue for background work, and a delivery layer for playback copies. Google Cloud’s reference flow for video processing starts with an upload to object storage, then submits an asynchronous transcoding job, then writes the output back to storage for serving. (docs.cloud.google.com, docs.cloud.google.com, docs.cloud.google.com) That setup changes the interview question from “where do the bytes go” to “which bytes stay hot, which move cold, and which can be recomputed.” Original uploads need high durability, metadata needs fast indexed reads, and derived renditions can be regenerated if policies and cost targets allow it. (docs.cloud.google.com, docs.cloud.google.com, x.com) Both prompts land in a hiring market where senior backend interviews still lean on security boundaries, storage tiers, queues, and failure handling rather than code puzzles alone. The value of these two posts is that each frames one concrete failure case — a hacked token in one, upload volume in the other — and forces the candidate to defend the tradeoffs. (x.com, x.com) The closing lesson in both diagrams is the same one interviewers usually test: “stateless” systems still keep some state somewhere, and “infinite” storage systems still depend on careful limits. (x.com, x.com, owasp.org)
