Trade-offs: Consistency, Caching, and Storage
In one line: consistency is chosen per dataset rather than per system, and being able to say why is what makes it a decision rather than a slogan.
How the requirements are met
| Requirement | How it's met |
|---|---|
| Low latency | ISP-level caching for popular content, storage tuned per data type, several cache layers, and CDNs serving from memory near the viewer |
| Scalability | Web and application servers scale horizontally. The relational tier does not, and needs sharding |
| Availability | Replication across servers and data centers; local and global load balancers reroute around outages |
| Reliability | Data partitioning isolates failures, a heartbeat protocol monitors health, and consistent hashing manages node churn |
Consistency, chosen twice
Most candidates pick one side of CAP and apply it everywhere. This design picks both, per data type.
Content: eventual. A video appearing for some viewers before others is invisible to users, and it buys asynchronous transcoding, lazy CDN population, and eventual metadata replication. The cost of being wrong is that someone sees a video a minute late.
User data: strong. A user who changes their password and finds the old one still works has experienced a failure, not a delay. Worse, a privacy setting that propagates eventually means a video the user just made private is still public somewhere — a real harm.
That asymmetry is only implementable because the storage clusters were decoupled in Lesson 4. Sharing one system would force the stricter guarantee onto both, paying strong-consistency costs on the far larger, far more write-heavy content dataset.
The transferable rule: consistency is chosen per dataset, not per system. Ask what staleness costs for each piece of data, and you will usually find it varies by orders of magnitude.
Distributed cache, and why LRU
A distributed cache removes the single point of failure that a centralized one introduces. Memcached-style key-value caching suits the static content here — thumbnails and segments — and the eviction policy is where the interesting choice sits.
The catalogue is dominated by the long tail: most videos are watched rarely, a few constantly. Under that distribution:
- LRU keeps whatever was accessed recently, which for skewed popularity naturally retains the hot set. A tail video watched once is evicted soon after, which is correct.
- LFU has a pollution problem. A video that was enormously popular last year retains a high total count and squats a cache slot long after interest died. On a platform where a news clip is hot for days, that failure mode is severe.
So LRU is not chosen for simplicity. It is chosen because recency predicts future access better than total frequency does when popularity decays quickly.
Three cache layers before origin
The distinction is real. Object caching avoids refetching a piece of data and composes across many different pages. Page caching avoids re-rendering a whole response and is reusable only for identical requests. Having both means a personalized page that cannot be cached as a whole still benefits from cached objects inside it.
Bigtable versus MySQL
| Store | Holds | Because |
|---|---|---|
| MySQL | User data, video metadata, renditions, comments | Structured, relational queries (a channel's videos, a video's comments), and ACID for the strong-consistency requirement |
| Bigtable / NoSQL | Thumbnail references, high-volume key-value data | Enormous object count, key-value access, no relational queries to run |
| Blob storage | Raw uploads, encoded segments, manifests | Large immutable objects, written once and read constantly |
Note what the requirements table already conceded: the relational tier has scaling limits that need sharding as the system grows. The design knows which tier constrains it, which is why the next lesson is entirely about Vitess.
That is a good pattern to imitate. Name the component that will break first, rather than presenting a design as uniformly scalable. Every system has a limiting tier, and identifying yours is more convincing than claiming none exists.
Key takeaway
Consistency is chosen per dataset — eventual for content, strong for user data — and is implementable only because storage was decoupled. The cache is distributed to remove a single point of failure, with LRU chosen because popularity decays fast and recency beats total frequency. Storage splits relational for structured data, key-value for volume, blob for bytes — and the design openly names the relational tier as what breaks first.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We use eventual consistency and a distributed cache, with SQL for metadata and NoSQL for videos." |
| L5 | Splits the consistency choice: "eventual for video content since nobody needs to see a new upload at the same instant, but strong for user data — a password change has to take effect immediately." |
| Staff+ | Explains why two models are possible and names the weak tier: "consistency is per dataset, not per system — and that's only implementable because we decoupled the storage clusters. Shared, we'd pay strong-consistency costs on the far larger content dataset. A privacy toggle propagating eventually means a video the user just made private is still public somewhere, which is a harm rather than a delay. And I'd name the relational tier as what breaks first rather than claiming uniform scalability." |
Next: CDN strategy, and what duplicate uploads actually cost.