Follow-Up Questions

In one line: these are the questions that naturally arise from the design, and several are deliberately hard — the useful skill is answering honestly rather than pretending the design covers everything.

1. How do you achieve 99.99% or 99.999% availability?

This is a hard question. In reality, such numbers are part of a service's SLA, generated from models or long-term empirical studies. It might be a better strategy to discuss the fault tolerance of the system — what happens with software faults, server failures, full data center failures. If the system is resilient against faults, that implies the system will have good availability.

The reframe is the answer — do not try to derive nines

An interviewer asking this is usually not looking for you to compute an availability figure. Deriving nines requires failure-rate data you do not have, and any number you produce is invented.

The strong move is to redirect to what produces availability: no single points of failure, replication across failure domains, automated failover, and graceful degradation. The Non-Functional Characteristics chapter made the point that four nines means minutes of downtime per month, which rules out human-in-the-loop recovery — that is a substantive answer where "99.99%" is not.

Answer with mechanisms, not with numbers you cannot justify. And if pressed for a figure, be explicit that it comes from measurement rather than design: "you get that number from monitoring an operating system, not from a diagram."

Answer this question with mechanisms, not with a derived number. Four nines is roughly four minutes of downtime a month, which is less than it takes to page someone — so the honest answer is that no human is in the loop, and you list what has to be automatic.

2. Are we designing for average behaviour?

The above numbers will likely change over time. Our system design should be horizontally scalable so the system keeps functioning with increasing users. Practically, systems might not scale when some aspect increases by an order of magnitude. When some aspect increases by 10x, we usually need a new, different design. Cost points of designing 10x and 100x scales are very different.

'10x needs a different design' is the most valuable sentence in this lesson

This is a genuinely important idea and it is easy to miss.

Horizontal scalability is often presented as though it extends indefinitely — add machines, handle more load. In practice, each design has a range of roughly one order of magnitude over which it works, and beyond that the bottleneck moves somewhere the design never anticipated.

This chapter contains its own example: MySQL worked, then required sharding, then required Vitess. That is not one design scaling; it is three designs, each replacing the one that ran out.

Two consequences for an interview:

Do not claim unlimited scalability. Say which range the design targets and what would break first beyond it — Lesson 6 and 8 name MySQL explicitly, which is a much stronger position than claiming everything scales.

Designing for 100x when you need 10x is over-engineering, because the cost points differ enormously. The right answer is a design that works now with a known migration path, not a design that would work at any scale.

3. Why no estimation for comments and likes?

Concurrent users' comments on videos are roughly at the same complexity as designing a messaging system.

Comments are a messaging system, and likes are a sharded counter

Comments belong with messaging rather than here, because a comment stream on a live premiere has the same shape as a chat room: high write rate, fan-out to many readers, ordering that matters within a conversation.

Likes are a different problem entirely, and the sharded-counters pattern solved it. A viral video's like count is the textbook heavy hitter: millions of concurrent increments to one counter, contention growing non-linearly. The answer is sharded counters with periodic aggregation — which is exactly why Lesson 4 noted that likes_count as an INT column is a logical view over a physically sharded counter.

Being able to say "comments are a messaging problem, likes are a sharded-counter problem, and they are different" is a good demonstration that you recognize sub-problems rather than treating "engagement" as one feature.

4. How do you manage unexpected load spikes?

Because our design is horizontally scalable, we can shed some load on the public cloud due to its elasticity features. However, public clouds are not infinitely scalable. They often need a priori business contracts that might put a limit on maximum, concurrently allowed resource use.

The caveat is the interesting half — cloud elasticity has contractual limits

"Just autoscale into the cloud" is the reflexive answer, and it does not survive contact: capacity is governed by contracts and quotas, not by an infinite pool.

Two real constraints. Quotas cap how many instances you can start in a region, and raising them takes days. And capacity is genuinely finite in any given zone — during a large-scale event, everyone tries to scale simultaneously.

This connects back to Lesson 7's CDN reasoning: public infrastructure absorbs unpredictable spikes precisely because you did not have to provision it in advance, and that is worth paying a premium for. Elastic overflow is a real strategy; unlimited elasticity is not.

5. How do you connect data centers and CDN sites globally?

YouTube uses Google's network, which is built for that purpose and peers with many ISPs of the world.

Owning the network is the logical endpoint of Lesson 7's build-versus-buy argument

Lesson 7 framed CDN ownership as a crossover: rent below a volume threshold, build above it. Owning the backbone is that same argument applied one layer down.

At sufficient scale, paying transit providers to carry your traffic becomes more expensive than laying your own fibre and peering directly with ISPs. Google, Meta, and Amazon all crossed that threshold and now operate private global networks.

It also explains why Lesson 10's ISP arrangements are feasible: a company that peers directly with an ISP has an existing relationship in which hosting a cache is a natural extension.

For a design interview, the honest framing is: "at this scale you own the network, which is why the delivery numbers work — but that is an option available to about five companies."

Owning the network is where the build-versus-buy argument from Lesson 7 ends up. Once you are moving petabytes between your own sites on a predictable schedule, paid transit is the expensive option and a private backbone amortizes quickly — the same crossover as the CDN decision, one layer down.

6. Why so little detail on encoding?

Due to excessive redundancy in multimedia content, encoding is often able to reduce a huge raw format content to a much smaller size (for example, from 600 MB to 30 MB).

20x compression is the number that makes the entire system affordable

That ratio — 600 MB raw to 30 MB compressed — is worth pausing on, because every estimate in Lesson 2 depends on it.

Without it, storage would be 20x higher (3.6 TB/min rather than 180 GB/min) and streaming bandwidth would be similarly multiplied. The system as designed would be unaffordable.

So codec efficiency is not a detail delegated to specialists; it is the enabling technology. That is also why Lesson 9's per-shot encoding earns a whole lesson — incremental gains on top of a 20x reduction are still enormous in absolute terms.

7. Can specialized hardware help?

When we estimated the number of servers, we assumed that any server could fulfill any required functionality. In reality, with the slowing of Moore's law, we have special-purpose hardware available — hardware encoders/decoders, machine-learning accelerators like Tensor Processing Units.

The uniform-server assumption in Lesson 2 is explicitly acknowledged as false

Lesson 2 computed 8K servers by dividing requests by a single RPS figure — which assumes every server is interchangeable.

Real workloads here are wildly heterogeneous: transcoding is compute-bound and benefits enormously from hardware encoders; recommendation inference wants ML accelerators; serving video bytes is I/O and network bound and needs neither.

So the real fleet is a mix of specialized machine types, and a single RPS constant cannot describe it. The Blob Store chapter made the same adjustment when it dropped per-server RPS from 64,000 to 500 for I/O-bound work.

Volunteering this is a good way to show you know the estimate is a model, not a measurement: "the 8K figure assumes uniform servers; realistically transcoding is a separate accelerator fleet sized on encoding throughput, not RPS."

8. Should compression happen client-side or server-side?

We might use some lossless but fast compression (for example, Google Snappy) on the client end to reduce data that needs to be uploaded. This might mean we'll need a rich client, or we would have to fall back to plain data if the compressor was unavailable. Both options add complexity.

Client-side compression trades upload bandwidth for client complexity — and upload is the cheap side

Compressing before upload reduces the 480 Gbps of ingress, which sounds attractive.

But Lesson 1 established the asymmetry: upload is the cheap side at 480 Gbps against 12 Tbps of egress. Optimizing the small term while adding client complexity and a fallback path is poor value.

Two further problems. You cannot rely on it — a browser upload has no guaranteed compressor, so you need the uncompressed path anyway, and now you maintain both. And video is already compressed; lossless compression on an already-compressed file yields almost nothing, which is why a fast lossless codec like Snappy is the only sensible choice rather than expecting large gains.

Optimize the expensive side. Here that is delivery, not ingest.

9. Other benefits of chunking?

Segmenting video also enables parallel preprocessing tasks such as transcoding and packaging, which is critical for low-latency live streaming.

Segmentation turns transcoding from serial into parallel — which is what makes live streaming possible

Lesson 9 introduced segments for encoding efficiency and Lesson 11 used them for adaptive bitrate. This is the third benefit and arguably the most consequential.

Transcoding a whole video is inherently serial — you process it start to finish. Transcoding segments is embarrassingly parallel: a hundred workers each take a segment, and a ten-minute video transcodes in the time of one segment plus coordination.

For uploads that turns hours into minutes. For live streaming it is the enabling requirement — you cannot wait for a stream to end before encoding it, so you must encode segments as they arrive.

That is a nice closing observation: one structural decision — segmentation — pays off in encoding efficiency, adaptive delivery, and parallel processing. Choosing the right unit of work is often worth more than optimizing any single operation.

One decision, three payoffs — and the third is the one that unlocks a different product. Serial transcoding means a video is available only after the whole file is processed; parallel transcoding means a segment is available as soon as that segment is done, which is the difference between video-on-demand and live.

Interview signal by level

Next: the whole design under interview conditions.