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.

Application Cache

Name: System Design Masterclass
Availability: InStock

A caches whatever your headers permit. A proxy caches responses. Neither of them has any idea what a user, an order or a permission is.

Two panels. The left, infrastructure cache, shows a request passing through something in front, then reaching your code which is unaware. Its key reads: decides what config, your code knows nothing, bugs live in the config. The right, application cache, shows a request reaching your own code, then the database on a miss. Its key reads: decides what your code, your code knows everything, bugs live in your code. — ComparisonFigure 1. The cache your code manages knows what the data means, and owns every mistake
Only your code knows that a leaderboard may be five seconds old, or that a permission check must not be. No layer above you has that information, and that is exactly why an application cache can do things a never could.

The price is that every correctness question is now yours, and this lesson is about the first one.

A sequence diagram with three lifelines: your code, the cache and the database. Your code asks the cache for user:42 and gets nothing. It queries the database and receives the row. It sets user:42 in the cache and answers the request, noted as four lines of code and the third is where the trouble is. — SequenceFigure 2. Four lines, and every application cache begins as these four lines
Look in the cache. If it is not there, ask the database, store it, return it. It is easy to write and easy to read, which is most of why it is everywhere. It is also correct, as long as nothing writes while a read is in flight.

The usual response is that the interleaving is unlikely. It is worth measuring instead of assuming, and the script is at scripts/labs/appcache/aside_race.py.

A recorded terminal session. A table with database read times of 0.5, 1, 2, 4 and 8 milliseconds across the top. Plain cache aside stores the wrong value in 6.0, 9.0, 17.3, 39.0 and 84.0 percent of trials. The same with a lock measures 5.3, 9.0, 15.7, 42.0 and 82.0 percent. A fill refused if the version moved measures 0.0 percent at every read duration. — RecordedFigure 4. The race, made to happen and counted, 300 trials per cell
The writer arrives at a uniformly random point in a ten millisecond window. The failure rate is simply the chance it lands inside the read, so it tracks the read time almost exactly.

A line chart of the percentage of fills that stored the wrong value, against how long the database read takes in milliseconds. Plain cache aside rises from 6 percent at 0.5 ms to 9 at 1 ms, 17.3 at 2 ms, 39 at 4 ms and 84 at 8 ms. A second line for the same pattern with a lock sits on top of it throughout. — ChartFigure 5. A two millisecond read on a key written every ten milliseconds loses one fill in six
At half a millisecond the rate is 6 percent, which sounds ignorable and is not. At eight milliseconds, an ordinary uncached join, 84 percent of fills store the wrong value. This is not an unlucky scheduler. It is one ordinary event overlapping another.

The two lines sitting on top of each other is the next finding.

Five rows. The instinct: two threads are racing, so add a lock. What the lock does: serialises the two writes to the cache. What the problem was: the reader is holding data that is already old. So the lock: changes nothing, measured at the same rate. What does work: refuse the fill if anything was written during the read. A closing line reads that mutual exclusion cannot help when the problem is that one thread's data went out of date before it took the lock. — FigureFigure 6. Adding a lock measured exactly the same failure rate
This is in the lab deliberately, because it is the first thing everybody reaches for and it looks like it should work. A lock guarantees the two cache writes do not interleave. It does nothing about the reader holding a row that was read before the write happened.

When a lock does not help, it usually means the race is not between two operations but between an operation and time.

A sequence diagram with four lifelines: a reader, the cache, the database and a writer. The reader misses and notes the version as 7, then reads name equals Ann. The writer writes name equals Anna and the version becomes 8, then deletes user:42. The reader finds the version is 8 and not 7, so the fill is refused, noted as the next reader misses and reads the correct value. — SequenceFigure 7. The reader checks whether the world moved, and gives up if it did
A miss is cheap. A poisoned entry is not. So when the two are in tension, throwing the fill away is always the right choice. Measured at zero failures across every read duration tested.

Every real implementation is a version of this. calls it WATCH, databases call it compare-and-set, and some caches use a delete marker that outlives the read. The shape is always: prove nothing changed, or do not write.