System Design: "Continue Where You Left Off" (Save User Progress)

Forty minutes into a lesson, the tab closes, and you're back on the home page. We design "continue where you left off" the way a real project grows: the URL and local storage for one laptop, progress on the server for many devices, two kinds of session, 20,000 writes per second at the peak, and what to do when two devices disagree. Every piece comes with the problem that asked for it and what it costs. You'll learn: • Why the URL and local storage are the right first answer, and their limits • When to save: why not on unload, and why visibilitychange is the last reliable moment • Moving progress to the server, and the two kinds of session (who you are vs where you were) • Write-heavy math: 200k students saving every 10 s is 20k writes per second • Scaling out a stateless backend, then fixing the database primary: save smarter, partition by student • Out-of-order saves from two devices, and the conditional update that keeps the newest Chapters 0:00 The question 0:12 Start simple 1:49 A second device 2:50 The login expires 3:18 A million students 4:56 Two devices disagree 5:32 When local is enough 5:46 Recap Browsers don't reliably fire unload or beforeunload, especially on mobile; MDN calls visibilitychange (hidden) the last event that's reliably observable by the page. Send the final save with navigator.sendBeacon (always a POST) or fetch with keepalive. localStorage survives closing the tab, holds about 5 MiB per origin, is synchronous and stores strings only. Private mode, clearing site data and Safari's 7-day cap on script-writable storage can wipe it. Return-to-page after login must accept only paths on your own site (OWASP: Unvalidated Redirects and Forwards). The numbers are our own example: 1M students, 20% watching at 8 pm, one save every 10 s = 20k writes/s; one app open per hour = ~55 reads/s. 💬 What would you have done differently? And which system should I design next? #systemdesign #backend #webdev