In the last chapter we found restaurants near you. This one looks almost identical — find friends near you — and it is a completely different problem.

Restaurants do not move. A restaurant’s location is written once and read a billion times, which is why that design could precompute an index, cache it globally, and rebuild it overnight.

People move. Every user is emitting a new location every thirty seconds, and every one of those updates has to reach a few hundred other people right now. The index is obsolete before you finish building it.

Every previous chapter optimised for latency, throughput or correctness. This one optimises for money, and that changes which answers are right.

Do the estimate before anything else. Five million daily users watching five videos of 300 MB each, served from a CDN at roughly $0.02/GB:

5,000,000 users x 5 videos x 0.3 GB x $0.02 = $150,000 per day

Fifty-five million dollars a year, in bandwidth alone. No database, no compute, no salaries — just moving bytes to viewers. That single number outweighs every other cost in the system, and it means a design that is elegant but bandwidth-hungry is simply a worse design.

Every social product has the same question at its centre, and it has exactly two answers:

Do you build a user’s feed when someone posts, or when that user opens the app?

That is it. Everything else — the caches, the queues, the graph database — follows from which side you pick. And the reason this is a great interview question is that both answers are wrong, in ways that only become visible when you do the arithmetic.

The algorithm for a web crawler fits on a napkin:

1. Take a URL off a queue.
2. Download the page.
3. Extract its links.
4. Put the new ones back on the queue. Repeat.

Write that and you have a crawler. Point it at the open web and within about ten minutes you will have been rate-limited, IP-banned, trapped in an infinitely deep calendar page, and served the same article eleven times under eleven different URLs.

You just landed an on-site interview at your dream company. The schedule lands in your inbox. Most sessions look manageable — coding, behavioural, a hiring manager chat. Then you see it: System Design Interview.

Your stomach drops.

“Design Twitter.”
“Build a URL shortener.”
“How would you architect YouTube?”

These questions feel impossibly broad. How could anyone design a system that took hundreds of engineers years to build — in 45 minutes? Here’s the secret that most engineers miss:

Imagine your interviewer says: “We’re designing Instagram Stories. How much storage do we need per year?”

Most junior engineers freeze. They don’t know where to begin. They feel like they need exact numbers — the real database size, the real compression ratios, the real usage stats.

Here’s the secret: you are not supposed to be exact. You are supposed to be directionally correct.

Back-of-the-envelope estimation is the skill of producing a reasonable answer in 2–3 minutes using simple math and a handful of memorized numbers. Google’s Jeff Dean calls it:

Designing a system that supports millions of users is challenging — it is a journey that requires continuous refinement and endless improvement. In this post, we build a system that supports a single user and gradually scale it up to serve millions of users. After reading this, you will master a handful of techniques that will help you crack system design interview questions.

A journey of a thousand miles begins with a single step. Building a complex system is no different.