We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A developer built an e-commerce checkout that stored the cart in a JavaScript variable. Users added items, browsed around, and hit refresh. Cart empty. Every page navigation, every accidental F5, everything gone. JavaScript variables live only as long as the page stays in memory, and the browser throws that memory away on every navigation.
The fix was two lines of code: localStorage.setItem('cart', JSON.stringify(items)) on every change, and JSON.parse(localStorage.getItem('cart')) on page load. Suddenly the cart survived refreshes, tab closures, even full browser restarts. But localStorage was the right choice here only because the cart data was small and did not need server access. A different use case needs a different storage mechanism.
Browsers ship four distinct storage APIs, each with different capacity limits, lifetimes, security properties, and access patterns. Picking the wrong one creates bugs that are hard to reproduce, security holes that leak tokens, or performance problems that freeze the main thread on mobile.
Every mechanism exists because the others cannot do its job well:
Cookies are tiny (4KB per cookie, roughly 80 cookies per domain) and the only storage sent automatically with every request. That automatic behavior is the entire point. Session tokens belong in cookies because the server needs them on every request. But that same behavior means storing 4KB of user preferences in cookies adds 4KB to every single request, including image fetches, API calls, and font downloads.
localStorage persists until explicitly cleared. The API is synchronous, meaning it blocks the main thread. Shopify's engineering team measured localStorage reads at 2-5ms on desktop and 10-30ms on older Android phones. For a handful of small values, that is fine. For hundreds of keys or values larger than a few KB, the main thread stalls.
sessionStorage is identical to localStorage in API and capacity, but it is scoped to the browser tab. Opening a link in a new tab creates a fresh sessionStorage context. Closing the tab destroys it. This makes it perfect for draft form data or wizard state that should not leak between tabs.
IndexedDB handles gigabytes of structured data with an asynchronous, transactional API. Google Docs stores offline document edits here. Figma caches design files. The API is more complex (open a database, create object stores, use cursors for queries), but it never blocks the main thread and supports indexes for fast lookups.