Amazon DynamoDB stores hundreds of trillions of items and handles tens of millions of requests per second at peak. Netflix uses it to keep track of what you were watching. Airbnb uses it for availability calendars. Discord uses it for message storage. What do all of these have in common? They all need to store and retrieve data by a simple key — blazingly fast, at global scale, with near-zero downtime.

Imagine you are the infrastructure engineer at a hot social media platform. Your system is humming along with 4 cache servers, each holding about 25% of your data. Life is good. Then your platform goes viral overnight. You urgently add a 5th server. You restart everything. And suddenly, your database is on fire — every single cache server is getting a tsunami of cache misses. Users experience 10× slower page loads.

It’s 11:59 PM on Black Friday. Your e-commerce platform has been running smoothly all day. Then at midnight, 500,000 shoppers simultaneously hammer your /checkout API. Your servers start queuing requests. Then they start dropping requests. Then they crash. Every second of downtime costs thousands of dollars in lost sales. Meanwhile, a competitor’s site — running the exact same infrastructure — handles the load just fine. The difference? They had a rate limiter.

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?

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.

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.