Netflix built its own CDN; Dropbox moved storage off S3. Both are usually wrong. What conditions made them right, and how do you test for those conditions?

What the interviewer is testing

Whether you can extract the conditions from a famous decision rather than the decision itself. These two cases are the most commonly misapplied in architecture discussions.

The conditions, and both cases meet all of them

1. The capability is the core domain, not an input. Netflix's product is bulk video delivery; Dropbox's product is storage. Owning it is owning the thing you are actually selling. For a retailer, storage is an input — a commodity to be bought.

2. It dominates the cost structure. Optimising something that is 60% of cost of revenue is strategic; optimising something that is 3% is a distraction with an opportunity cost.

3. The workload is narrow enough to specialise for. Custom infrastructure beats a general-purpose managed service only when you can exploit properties the general service must not assume. Netflix knows what will be popular tomorrow in each region, so appliances can be filled off-peak. Dropbox stores immutable blocks and nothing else.

4. The scale makes a small efficiency gain worth millions. A 10% improvement must exceed the fully-loaded cost of a specialist team, indefinitely.

5. The capability exists in-house, and the commitment is multi-year.

How to test for them

Not with a feature comparison. Three concrete tests:

• Compute the fully-loaded five-year TCO of both, including the team you must hire and retain, the opportunity cost of what they would otherwise build, and the exit cost of each path.
• Name the specialisation. What property of your workload lets you beat a general-purpose provider? If you cannot state it in one sentence, you will not beat them.
• Check the cost share. If this line is not among your largest, the ceiling on the win is low regardless of how well you execute.

The nuance both cases show

Neither went all in. Netflix runs its control, encoding and business systems on AWS while running delivery itself. Dropbox retained public cloud for regions and workloads where it made more sense. Both answered build-versus-buy twice, with different answers, because the two workloads had different economics.

That is the mature version of this decision: it is per capability, not per organisation, and it is revisited as scale changes.

What a strong answer adds

Naming the symmetric error. Generalising Dropbox's answer to an ordinary estate is one mistake; treating an early buy decision as permanent is the equal and opposite one. The right choice at \(10M of annual spend across a diverse workload is genuinely not the right choice at \)100M concentrated in one — and organisations rarely re-examine the decision when they cross that line.