How Every Case Study Is Structured

The two halves

The steps split into two groups, and the split matters.

The first three steps happen before you draw anything. They are cheap to do and cheap to redo. Most weak interviews skip them and start drawing boxes in the first two minutes.

The rest is the design itself. Each of those steps depends on an answer from the group before it.

Step 1: System definition

State in two or three sentences what the system does. Name the main entities and who uses them.

This sounds trivial and it is not. "Design Reddit" can mean the posting system, the ranking system, or the comment tree. Saying which one you are designing, out loud, is the first thing a senior candidate does.

The common mistake is starting to design before the problem has a boundary.

Step 2: Requirements

Split them in two. Functional requirements are what the system does. Non-functional requirements are how well it has to do it.

Functional: a user can post, vote, and see a feed. Non-functional: the feed loads in under 200 milliseconds, and the system stays available if one data center is lost.

The non-functional list has more effect on the design than the functional one. Strong consistency for a payment and eventual consistency for a like count lead to two completely different systems.

The common mistake is a requirements list so long that nothing is prioritized. Three or four of each is usually enough.

Step 3: Back-of-the-envelope estimation

Work out the rough size with arithmetic you can do in your head. Daily users, actions per user, bytes per record. From those, get writes per second, reads per second, and storage per year.

The point is not accuracy. The point is finding the number that limits your options. Sometimes it is a read to write ratio of 100 to 1, which means caching. Sometimes it is a single row that every request touches, which means contention.

Every case study here shows its assumptions separately from the numbers derived from them. That separation is the skill. If you cannot tell which is which, you cannot check the arithmetic or argue with the inputs.

The common mistake is treating this as a formality and never using the numbers again.

Step 4: High-level design

Draw the main parts and the paths between them. Client, gateway, services, queues, stores. Keep it to a handful of boxes.

An interviewer should be able to follow one request across your diagram while you talk. If they cannot, the diagram has too much in it.

Step 5: Data model and APIs

Choose your storage and say why. Show the main tables or collections, with the keys that matter.

Then define the few API calls that carry the real traffic. Not every endpoint, just the two or three that matter most.

In some case studies the API gets its own step, and in others it sits inside the high-level design. The order is a guide, not a form to fill in.

Step 6: Detailed component design and scale

Pick the two or three hard parts and explain them in detail. In a notification service it is fan-out. In a flash sale it is the inventory decrement. In a payment system it is exactly-once behavior.

Then say how the design grows: what you shard on, what you cache, where the hot spot is, and what happens when a part fails.

The common mistake is spreading equal attention over every component. Interviewers want depth on the hard part, not equal coverage of the easy ones.

The order is not decoration

Each step uses the answer from the step before it.

Your estimate depends on the requirements. Your storage choice depends on the estimate and on the consistency you promised. Your sharding key depends on the access pattern in your API.

This is why skipping ahead does not work. A candidate who picks a database in minute three is guessing, and a good interviewer will ask what the choice was based on.

Key Takeaways

• Every case study answers the same questions in roughly the same order.
• The first three steps happen before any boxes are drawn, and they are the ones most candidates skip.
• Requirements, especially the non-functional ones, affect the design most.
• Estimation matters because it finds the one number that limits your options.
• Go deep on the two or three hard parts, not evenly across everything.
• The order exists because each step consumes the answer from the one before it.

You now know the shape of what is coming. Open the first case study and try it yourself before you read it.