5 exercises — clarifying requirements, back-of-envelope estimation, trade-off vocabulary, CAP theorem language, and scaling discussions.
0 / 5 completed
1 / 5
You're asked: "Design a URL shortener like bit.ly." What is the most professional opening move?
Clarifying requirements first is the single most important move in a system design interview. It demonstrates seniority, structured thinking, and communication ability. The formula: "Before I start, let me clarify a few things." Then ask about: scale (QPS, DAU), availability requirements, latency constraints, geographic distribution, and any known edge cases. Option B jumps to a solution without understanding the problem — a common mistake. Option A shows you're moving without direction.
2 / 5
You are estimating scale. Complete the statement: "Let's _____ we have around 10 million daily active users. If each user makes _____ 3 requests per day on average, we're looking at _____ 30 million requests per day, or _____ 350 requests per second."
The hedging vocabulary for system design estimation: assume (basis for calculation), approximately / roughly (imprecise number), and about / around (order-of-magnitude estimate). These signal that you're making reasonable back-of-envelope calculations, not exact predictions. The interviewer knows you're estimating — using these words shows honesty and precision about your uncertainty. Avoid "guess" (too casual) or exact numbers without a qualifier.
3 / 5
The interviewer asks: "Would you use SQL or NoSQL for this system?" Which response demonstrates the strongest thinking?
System design answers must be trade-off driven. The phrase "It depends on…" followed by explicit criteria is a strong signal of senior engineering thinking. Structure: "If [condition A], I'd use X because [reason]. If [condition B], Y is better because [reason]. Given our requirements, I'd lean towards X." Option A reveals personal bias, not engineering judgment. Option B states an incorrect universal rule. Option D avoids the question — interviewers are probing your decision-making process.
4 / 5
You're explaining a trade-off between consistency and availability. Which vocabulary choice is most precise and professional?
A strong system design explanation: (1) names the framework (CAP theorem), (2) defines terms ("availability — meaning the system stays up"), (3) presents the trade-off symmetrically ("if we prioritise X… if we prioritise Y…"), and (4) states the outcome of each choice (stale data vs. rejected reads). Key phrases: "we accept that…", "meaning that…", "the trade-off is…". Option A is too vague for an interview. Option C is too informal.
5 / 5
You've finished your design and the interviewer asks: "What would you do differently if the read traffic increased by 100x?" Complete the best response: "Good question. I _____ add a read replica layer in front of the primary database. _____, I'd also consider introducing a caching layer — Redis, for example — _____ frequently read data. _____ would handle most read traffic and take pressure off the database."
"Would" (conditional) is the correct form when answering hypothetical scaling questions — it signals you're reasoning about a scenario, not making a firm commitment. Structure: state the primary change → use "Additionally" to layer a second improvement → explain the why → summarise the combined effect with "This combination". Good sequencing language: "First… Additionally / On top of that… This combination / Together, these changes…" signals that you have a complete plan, not individual ad hoc fixes.