Mock System Design Interviews

# CHAPTER 18

Mock System Design Interviews #

1. Chapter Introduction #

Knowledge is useless if you cannot communicate it under pressure. The System Design Interview is not a test with a single correct answer; it is a 45-minute collaborative roleplay where you act as the Senior Architect and the interviewer acts as the Product Manager. This chapter provides a rigid framework for managing the clock, leading the conversation, dominating the whiteboard, and transforming a terrifying interrogation into a peer-to-peer engineering discussion.

2. The 45-Minute Timeline (The Framework) #

If you just start drawing boxes the moment the prompt is given, you will fail. You must actively manage the time.

• Phase 1: Clarify Requirements & Scope (0-5 mins)

• Phase 2: Back-of-the-Envelope Estimation (5-10 mins)

• Phase 3: API & Database Design (10-15 mins)

• Phase 4: High-Level Architecture (15-25 mins)

• Phase 5: Deep Dive & Bottleneck Resolution (25-40 mins)

• Phase 6: Wrap-up & Edge Cases (40-45 mins)

3. Phase 1: Clarify Requirements (The Trap) #

*Prompt:* "Design Ticketmaster." *The Trap:* Ticketmaster does 50 things (Selling tickets, generating QR codes, managing artist payouts). If you try to design all 50, you will fail. *The Action:* Ask clarifying questions to narrow the scope.

• "Are we focusing strictly on the ticket purchasing flow, or do we need to design the event creation portal for artists?" (Focus on the purchasing flow).

• "Are we building this for mobile, web, or both?"

• *Write the agreed-upon 3 core features in the top-left corner of the whiteboard.*

4. Phase 2: Back-of-the-Envelope Estimation #

You must calculate the scale to justify your database choices. *The Action:* Establish Read/Write ratios.

• "Assuming 10 million Monthly Active Users."

• "The system is highly Read-Biased (100 people view an event for every 1 person who buys a ticket)."

• "Assuming 1KB per ticket, 1M tickets a month = ~1GB of text data per month. Storage is not our primary bottleneck, but concurrent Read throughput is."

5. Phase 3: API & Database Design #

Before drawing servers, define the data contract. *The Action:* Write out 2-3 core REST endpoints.

• POST /api/v1/tickets/purchase (Payload: userid, eventid)

• GET /api/v1/events/{id}

*The Action:* Draw the Database Schema.

• "We need strict ACID compliance for financial ticket transactions, so I will choose PostgreSQL."

• Draw tables: Users, Events, Tickets.

6. Phase 4: High-Level Architecture #

Now, you draw the boxes. Start simple. Establish the baseline. *The Action:* Draw the flow from left to right.

1. 1. Client (Mobile App) -> 2. CDN (For event images) -> 3. Load Balancer -> 4. Stateless Web Servers -> 5. PostgreSQL Master DB.

*Crucial Step:* Explain the flow verbally as you draw it. "The user's HTTP request hits the Load Balancer, which uses a Round Robin algorithm to select a Web Server..."

7. Phase 5: Deep Dive & Bottleneck Resolution #

This is where you earn your Senior title. The interviewer will attack your baseline architecture. *Interviewer Attack:* "Taylor Swift just announced a concert. 1 million people try to hit the GET /api/v1/events/{id} endpoint in 1 minute. Your PostgreSQL database crashes. Fix it." *Your Defense (Scaling):*

• "I will implement a Redis Cache between the Web Servers and the Database to serve the Event Details in memory, bypassing the database entirely."

• "I will add Read Replicas to the PostgreSQL setup."

*Update the whiteboard to reflect these changes.*

8. Handling Pushback (The Collaborative Mindset) #

If the interviewer says, "I don't think a relational database is a good idea here," DO NOT argue angrily. *The correct response:* "That is a fair point. A NoSQL store would give us better horizontal write scaling. Let's look at the tradeoffs. If we switch to Cassandra, we gain scale, but we lose ACID transactional guarantees for the checkout process. How would you recommend we handle the double-booking problem in a NoSQL environment?" *Turn it into a peer-to-peer tradeoff discussion.*

9. Mini Project: Conduct a Solo Mock Interview #

Record yourself on video for 20 minutes answering the prompt: "Design a Global Photo Sharing App (Instagram)."

1. 1. Speak out loud.

1. 2. Ask the clarifying questions to the camera.

1. 3. Draw the architecture on a piece of paper and hold it up.

1. 4. Watch the recording. Did you speak clearly? Did you justify your database choice? Did you mention a CDN?

10. Common Mistakes #

• The Silent Artist: Drawing on the whiteboard for 10 minutes in total silence. The interviewer cannot read your mind. You must narrate every single line you draw.

• Defensiveness: Getting defensive when the interviewer points out a flaw in your design. They *want* to find flaws to see how you adapt.

11. Best Practices #

• Drive the Interview: You are the architect leading the meeting. Do not wait for the interviewer to prompt you. "I've finished the API design, I am now going to move on to the High-Level Architecture. Does that sound good?"

12. Exercises #

1. 1. What are the three non-functional requirements (Estimations) you must define in Phase 2?

1. 2. If an interviewer asks you to "Design Facebook," write down the specific clarifying question you would ask to narrow the scope.

13. MCQs #

14. Interview Questions #

• Q: "Let's begin. Design a parking garage ticketing system. You have 45 minutes. Go." (Practice taking control of the first 5 minutes of this prompt).

15. FAQs #

• Q: What if I don't know the answer to a deep-dive question?

A: Be honest, but pivot to principles. "I haven't personally implemented Cassandra for that specific edge case, but fundamentally, I know Wide-Column stores handle massive writes well. I would approach researching the solution by..."

16. Summary #

Acing the System Design interview is 50% technical knowledge and 50% communication framework. Take control of the clock. Spend the first 15 minutes defining the scope, the scale, the APIs, and the Database schema. Draw a simple baseline architecture, explain it out loud, and let the interviewer attack it. When they find a bottleneck, defend it with Caching, Message Queues, or Sharding. Above all, treat it as a collaborative engineering discussion.

17. Next Chapter Recommendation #

You know the framework. Now you need the raw ammunition. In Chapter 19: System Design Interview Preparation, we will provide a massive rapid-fire list of the top 50 system design questions, architecture exercises, and cheat codes.