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.

Server-Side Caching

Name: System Design Masterclass
Availability: InStock

Caching the Answer Instead of the Ingredients

Every cache so far has made part of the work cheaper. A query cache saves a query. A shared cache saves a computation. The response still has to be assembled each time.

Two panels. The left, caching the ingredients, shows a request where your code still runs, fanning to cached queries and the rest. Its key reads: skips some queries, still does templates and logic, works with personalisation. The right, caching the answer, shows a request where your code never runs, ending in bytes straight from memory. Its key reads: skips everything, still does nothing, needs one answer for all. — ComparisonFigure 1. A full-page hit skips the queries, the templates, the logic and your application
The leverage and the constraint are the same fact. Because nothing runs on a hit, nothing can adapt to who is asking, and the whole engineering problem of server-side follows from that.

What It Buys, and What One Element Costs

The script is at scripts/labs/serverside/fullpage.py. It runs a real origin that takes 25 milliseconds to render, a real caching reverse proxy in front of it, and 120 real requests each time.

A recorded terminal session. Straight to the origin measured 35.6 milliseconds at the median, 29 requests per second and 120 renders. Through the cache on a public page measured 0.3 milliseconds, 1,580 per second and 1 render. Through the cache with one personal element measured 35.5 milliseconds, 29 per second and 120 renders. The proxy counters read 119 hits, 1 miss and 120 refused as uncacheable. — RecordedFigure 2. 54 times faster, and one personalised element returning all of it
On a hit the application never ran at all. With one personalised span in the page it ran 120 times, and the 4,000 bytes that were identical for every visitor were re-rendered every single time.

A bar chart of requests per second. Straight to the origin is 29. The cached public page is 1,580. The page with one personal element is 29. — ChartFigure 3. HTTP caches whole responses, so there is no partial hit
A page that is 99 percent identical and 1 percent personal is 0 percent cacheable. That is not a limitation of this proxy, it is how HTTP is defined.

A sequence diagram with three lifelines: a visitor, the proxy cache and your application. The visitor requests slash personal. The proxy has nothing stored so it asks the application, which returns the page with Cache-Control private, no-store, noted as one header the proxy must obey. The proxy returns the page stored nowhere. The next visitor asks for the same URL and the proxy asks again, 120 times in the measurement. — SequenceFigure 4. The proxy refused to store it 120 times, and was right every time
Storing a response marked private is the incident from earlier in this chapter, where one user is served another user's page. Do not look for a way to make the cache store the private page. Look for a way to make the page not private.

Getting the Personal Part Out

A large hand-drawn rectangle labelled the page, identical for every visitor, with a small highlighted box in its corner labelled your name. Labels beneath read 95 percent cacheable forever and 5 percent personal. A handwritten note reads: http caches whole responses, so the small box makes the big one uncacheable. — SketchFigure 5. The small personal part governs the whole thing
A product page, an article, a search result: the content is the same for everybody, and a greeting or a basket count in the corner is not. Every technique that follows is a different way of separating those two boxes.

Five approaches with who assembles the page. Page cached, person fetched: one cached response and one small API call, the browser joins. Edge side includes: the proxy assembles the fragments, the proxy joins. Fragment cache in the app: cache pieces and render the page each time, the app joins. Cache per user: correct, and the hit rate collapses, no join at all. Do not cache: what most teams end up doing by default, nothing joins. — FigureFigure 6. Five approaches, and the last two are what happens when nobody chooses
The first three all work. They differ in who assembles the page, and that decides which team carries the complexity and where it fails.

A sequence diagram with three lifelines: the browser, the proxy cache and your application. The browser requests a product page and the proxy returns the whole page from cache in 0.3 milliseconds, noted as no application code ran. The browser then requests slash api slash me, a few hundred bytes, and the application returns the name and basket count. The browser fills in the corner of the page.

Where It Sits, and the Headers That Drive It

A flowchart from left to right: browser, CDN edge, reverse proxy running nginx or varnish, your application, and from there both a shared cache and a database. A dotted line from the CDN edge to the reverse proxy is labelled same idea, somebody else's machines. — FlowchartFigure 9. A CDN and a reverse proxy are the same mechanism at different distances
Both store finished responses and both obey the same headers. If a response is cacheable at the it is cacheable at the proxy, and the reverse is not true, which makes the proxy the right place to start.

Six headers. Cache-Control public with s-maxage 60 means shared caches may store it for a minute. Cache-Control private means browsers only, no proxy and no CDN. Vary Accept-Encoding gives one entry per compression format, which is fine. Vary Cookie gives one entry per cookie value and is never cacheable. Surrogate-Control gives instructions for the proxy that the browser ignores. stale-while-revalidate 30 serves the old one while fetching a new one. — FigureFigure 10. Six headers, and Surrogate-Control lets you treat the two layers differently
Reach for `s-maxage` before `Surrogate-Control`. It is standard, widely supported, and covers the common case of a long proxy cache with a short browser cache, which is the split the browser lesson argued for.

Freshness, Load and the Cold Start

Two panels. The left, let it expire, shows s-maxage 60 leading to being wrong for up to a minute, with nothing to operate. Its key reads: publishing takes up to the TTL, needs nothing, fails predictably. The right, purge on publish, shows an editor saving, telling every cache to drop it, correct in seconds. Its key reads: publishing takes seconds, needs a purge path, fails quietly. — ComparisonFigure 13. A TTL costs a minute of staleness. A purge costs a mechanism that must keep working
This is the same argument as the lesson, one layer up. Most designs use both, with the TTL as the backstop, so the day somebody forgets to purge the damage is bounded rather than permanent.

A line chart of the percent of traffic reaching your application against the percent of requests served from the proxy cache. It falls from 100 percent at zero to 50 at 50, 20 at 80, 10 at 90, 5 at 95 and 1 at 99. — ChartFigure 14. At a 95 percent hit rate your application is sized for five percent of your traffic
That is the real reason to put a cache in front of an application. It also means a cache outage delivers twenty times the load to an origin that was never sized for it.

A sequence diagram with three lifelines: Ops, the proxy cache and your application. Ops restarts the proxy or deploys a config change. The cache is now empty. Every request is a miss all at once, noted as twenty times the traffic it was sized for. If the application survives, the cache refills in seconds.

Choosing, Watching and Wording

A flowchart. For a page or endpoint, it asks whether the response is identical for every visitor. If yes, cache it at the proxy and the CDN with public and s-maxage. If no, it asks whether the differing part is small and separable. If yes, cache the page publicly and fetch the personal part from its own endpoint. If no, it asks whether it is read far more often than it changes. If yes, micro-cache it, since even one second removes almost all the load. If no, do not cache the response, cache its ingredients instead. — FlowchartFigure 16. Four questions, and the second is where most of the work is
The last branch does not describe a failure. the ingredients is what the application cache, shared cache and query cache lessons were about, and a page that cannot be cached whole is still made much cheaper by caching what it is built from.

Five metrics. Requests reaching the origin, the number the application is sized against. Hit ratio at the proxy, useful here unlike at the object level. Responses refused as uncacheable, the counter that finds a stray Set-Cookie. Cache size against the limit, where full means eviction of things you wanted. Origin p99 during a cache restart, the number your cold start plan needs. — FigureFigure 17. Five numbers, and the third explains a hit rate nobody can account for
Graph the refusal counter next to the hit ratio. A low hit ratio is ambiguous, and a high refusal count tells you immediately that the problem is a response header and not traffic shape or cache size.

Quick Check

Knowledge Check

4 questions - Score 80% to pass

Q1

A page renders in 25 ms. Behind a full-page cache it served 1,580 requests per second. Adding a greeting with the visitor's name changed that to what?

Q2

Your proxy cache refuses to store a page. What is the fastest way to find out why?

Q3

A proxy cache serving 95 percent of your traffic is restarted for routine maintenance. What should you expect?

Q4

A page is technically dynamic and requested 50 times a second. What does one second of full-page caching do?