Is this a video course?

No. This is an interactive, slide-based learning platform. Each lesson has rich text, animated diagrams, live code editors, and quizzes. You learn by reading, interacting, and doing, not by watching videos passively.

How long do I have access?

Forever. Both pricing tiers are one-time payments with lifetime access. This includes all current 766 lessons and any future content we add.

What level of experience do I need?

None. We start from absolute basics like 'What is latency?' and build up to distributed consensus protocols. The Foundation level assumes zero prior knowledge of system design.

How much does the system design course cost?

7.99 US dollars for lifetime access globally, or 499 Indian rupees for lifetime access in India. One-time payment, no subscription, no hidden fees. 11 lessons are free with no signup required.

What technologies are covered?

Everything from DNS and load balancers to Kubernetes, Kafka, distributed databases, consensus protocols, stream processing, security architecture, and observability. We cover principles and real-world implementations used at Netflix, Google, Amazon, Uber, Stripe, and more.

Is this useful for system design interview preparation?

Yes. The lessons are structured around the exact topics asked in system design interviews at FAANG and top-tier companies. Interactive diagrams help you practice whiteboard-style explanations. Covers everything from URL shortener design to distributed payment systems.

How is this different from ByteByteGo or Educative?

766 interactive lessons (4x more than most competitors), 16 different diagram types that build step by step, real production examples from Netflix, Google, Amazon, Uber, and Stripe, and lifetime access for a one-time payment of $7.99 instead of annual subscriptions costing 100 to 200 dollars per year.

Client-Side Caching

Name: System Design Masterclass
Availability: InStock

The last lesson was about a cache the browser operates on your behalf, driven entirely by response headers. This one is about a cache you build yourself, in storage you choose, holding your objects rather than responses.

Two panels. The left, the HTTP cache, shows a response going through the browser deciding, ending in headers being the only control. Its key reads: keyed by the URL, you control via headers, expires on its own. The right, your client cache, shows an object going through your code deciding, ending in storage you chose. Its key reads: keyed by whatever you like, you control all of it, expires never unless you say. — ComparisonFigure 1. The HTTP cache stores responses. This one stores your objects
The freedom is the point and it is also the problem. There is no `Cache-Control` here, no unless you build one, and no eviction until the browser runs out of room. Every mechanism that made the last lesson tractable is absent.

Before deciding what to put there, it is worth settling the objection everybody raises.

The usual argument against client is that deserialising costs more than people think. Getting a cached object back into usable JavaScript means parsing it, and JSON.parse is work on the same thread that draws the page.

That is a real concern, so this lesson's lab was written to demonstrate it. The script is at scripts/labs/clientcache/parse_cost.mjs.

Four hand-drawn boxes: in memory, sessionStorage, localStorage and IndexedDB, with the last highlighted. Labels beneath read gone on reload, gone with the tab, about 5 MB and sync, and hundreds of MB and async. A handwritten note reads: only the last one is both large and off the main thread. — SketchFigure 5. Four options, and only one is both large and asynchronous
The synchronous part of localStorage is the argument against it, not its size. Every read and write blocks the thread that draws the page, so a large localStorage read during start-up delays the first paint by exactly that long.

A bar chart of typical usable megabytes per origin on desktop. sessionStorage is 5, localStorage is 5, IndexedDB is about 400 and the Cache API is about 400. — ChartFigure 6. The two easy options stop at five megabytes
IndexedDB and the Cache API share one origin quota, commonly a share of free disk, so the real number depends on the user's machine and shrinks on a full device. Exceeding it does not warn you, it throws.

Two panels. The left, localStorage, shows strings only going through synchronous, ending at about 5 MB. Its key reads: blocks the page yes, query by field no, good for small settings. The right, IndexedDB, shows structured objects going through asynchronous, ending at hundreds of MB. Its key reads: blocks the page no, query by field yes with indexes, good for real datasets. — ComparisonFigure 7. One of these blocks the thread that draws your page
Use localStorage for a handful of small values where the synchronous cost is microseconds. Use IndexedDB, through a wrapper, for anything you would describe as data. The dividing line is roughly where you stop being able to name every key.

Three hand-drawn bars showing your origin's data, then disk filling up, then the browser clearing the least recently used origins, with the last highlighted and much shorter. A handwritten note reads: no warning, no event, and your code finds out by getting null. — SketchFigure 8. The browser can empty your cache whenever the device runs short of space
The eviction is silent, and it is most likely on the devices with the least free space, which are the oldest phones. Write every client cache read as though the value may be missing, because it may be, and not only on a first visit.

A sequence diagram with three lifelines: Tab A, localStorage and Tab B. Tab A loads the cart and holds it in memory. Tab B loads the same cart into its own copy. The user removes an item in Tab A, which writes the new cart. Tab B is still showing the removed item, noted as nothing told Tab B anything changed. — SequenceFigure 9. Two tabs are two instances, with the same problem as two servers
This is the local cache lesson again at the other end of the connection, and it is worse here, because the user can see both copies at once.

The storage event fires in other tabs when localStorage changes, and almost nobody listens for it. A BroadcastChannel does the same job more clearly. If your application can be open twice, the tabs need a way to tell each other something changed.