5 exercises — practise the vocabulary of system design interviews: why to clarify requirements first, back-of-the-envelope estimation naming and technique, bottleneck mitigation vocabulary, SPOF analysis and redundancy patterns, and scaling sequencing rationale.
0 / 14 completed
1 / 14
You are in a system design interview. The interviewer presents the problem and you respond: "Before I start drawing the design, let me clarify a few requirements." You then ask about scale, latency requirements, consistency needs, and read/write ratio. What does this behaviour communicate to the interviewer about your engineering seniority?
System design interview vocabulary — requirements clarification phase:
Requirement clarification is not timidity — it is the expected behaviour of a senior engineer who understands that the correct design is impossible to determine without knowing the constraints. Interviewers who conduct system design interviews consistently say that engineers who skip this phase often design the wrong system entirely.
Category
Questions to ask
Why it matters for design
Functional requirements
What are the core features? What is out of scope?
Determines which components to include — e.g., whether you need a search index
Scale
DAU? QPS? Data volume? Growth rate?
Determines whether you need sharding, caching, CDN, and which database to choose
Latency SLA
p99 read latency? Write latency? Acceptable for all users?
Determines whether you need a caching layer, co-located data, or edge delivery
Consistency
Is eventual consistency acceptable? Which operations require strong consistency?
Drives database choice and replication strategy
Standard opening vocabulary phrases:
"Before I start, let me make sure I understand the scope and constraints."
"I'll clarify requirements first so the design addresses the actual problem."
"A few questions to establish the scale context — this will drive most of the component choices."
2 / 14
In a system design discussion you say: "Based on 10 million DAU, with roughly 100 requests per user per day, that gives us about 10 billion requests per day — approximately 115,000 requests per second at peak." Which vocabulary term correctly names this estimation method?
Back-of-the-envelope estimation vocabulary:
The phrase "back-of-the-envelope estimation" is the standard term for this technique in system design discussions. It signals fluency with the design interview vocabulary and the habit of grounding architecture in numbers before making component choices.
Metric
Common approximations to know
Seconds per day
~86,400 ≈ 100,000 (10^5)
1M requests/day
~12 requests/second
10M requests/day
~115 requests/second
1B requests/day
~11,500 requests/second
1 KB × 1M records
~1 GB storage
1 KB × 1B records
~1 TB storage
Vocabulary phrases to use in estimates:
"Let me do a quick back-of-the-envelope to validate the scale before choosing components."
"Assuming 10M DAU and a 10:1 read/write ratio, the write path sees roughly X QPS."
"At this scale, a single database node handles ~10K QPS — we'd need at least [N] replicas."
"The storage estimate comes out to [X] TB per year — that drives the choice between object storage and a block device."
3 / 14
You identify a bottleneck in a system design discussion: "At this scale, the database read path will be the bottleneck — the primary will saturate at around 50K QPS." What vocabulary and mitigation proposals correctly follow this bottleneck identification in a senior-level system design discussion?
Bottleneck mitigation vocabulary — read path:
Identifying a bottleneck without proposing named, specific mitigations with trade-offs is incomplete in a system design interview. Option A uses the correct vocabulary and distinguishes three complementary tools, each serving a different part of the read path.
Mitigation
What it does
Accepted cost
When to use
Read replicas
Routes read traffic to replicated copies of the primary, reducing primary QPS
Replication lag — reads may be slightly stale
Read-heavy workloads; when eventual consistency is acceptable
Caching layer (Redis/Memcached)
Serves hot data from in-memory store at sub-millisecond latency without touching the database
Cache invalidation complexity; stale data up to TTL
Repeated reads of the same data; low mutation rate on hot keys
CDN
Delivers static or cacheable content from edge nodes geographically close to users
Cache invalidation; not suitable for personalised or dynamic content
Images, JS/CSS bundles, API responses that are user-agnostic
Vocabulary phrasing after bottleneck identification:"To address the read path bottleneck, I'd introduce a Redis caching layer for the top 10% of hot user profiles — that should reduce database QPS by around 80%. For remaining reads, we add two read replicas behind a load balancer. The accepted trade-off is up to [N]ms staleness on profile data."
4 / 14
A system design reviewer says: "Your current design has an SPOF at the load balancer — if it goes down, everything behind it is unreachable." What must the engineer propose to correctly address a single point of failure?
SPOF vocabulary — single point of failure analysis:
A single point of failure (SPOF) is any component whose failure causes the entire system to become unavailable. Addressing an SPOF always means introducing redundancy — a backup component that takes over when the primary fails.
Redundancy pattern
Description
Failover time
Active-passive
Primary handles all traffic; standby takes over only on failure (promoted via VIP or DNS change)
Seconds (health check interval + promotion time)
Active-active
Both instances handle traffic simultaneously; if one fails, the other absorbs full load
Transparent — provider handles failover below the SLA
SPOF vocabulary for system design discussions:
SPOF (Single Point of Failure): a component whose failure causes a system-wide outage
Redundancy: having multiple instances so failure of one does not cause a service outage
Failover: the automatic (or manual) switch to a backup component when the primary fails
VIP (Virtual IP): a floating IP address that moves to the active node in active-passive setups
Health check: periodic probe to determine whether a component is serving traffic correctly
Design review vocabulary:"Every tier in the architecture should be evaluated for SPOFs. The load balancer is one; the primary database is another. For each, I have a redundancy strategy: active-active LB pair, and a read replica promoted via automated failover."
5 / 14
You propose: "I would start with vertical scaling for the database — resize to a larger instance — and only introduce horizontal sharding if we hit write throughput limits at that tier." Why is this sequencing professionally preferred over jumping to sharding immediately?
Option D correctly articulates the engineering principle: accidental complexity should not be introduced until necessary. Sharding is one of the highest-complexity database operations; it is a poor choice as a first response to a scaling problem when simpler options exist.
Very high — shard key design, data migration, cross-shard queries, distributed transactions
Yes — significant application changes
Very high — re-merging shards is expensive
Architecture discussion vocabulary for this principle:
"We should exhaust simpler scaling options before accepting the distributed complexity of sharding."
"Premature sharding is a common and expensive mistake — the operational and application complexity is high, and it's difficult to undo."
"The threshold for introducing sharding is when write throughput or data volume genuinely exceeds what a well-tuned single node can handle — not as a preemptive measure."
6 / 14
Sarah (Lead Engineer) comments on your PR: 'This implementation lacks clear retry logic. What happens if the external API fails? We need to ensure eventual consistency and handle transient errors gracefully.' Which of the following best captures Sarah's concern regarding system resilience?
Sarah's comment highlights the importance of resilience in system design. The key takeaway here is that 'appropriate' reflects a professional understanding of error handling and eventual consistency – a senior engineer would proactively address transient failures, not simply assume perfect reliability. Options A and B demonstrate a lack of awareness regarding potential issues, while option C suggests an overly simplistic approach.
7 / 14
During a Slack discussion about designing a new user profile service, David (Junior Dev) says: 'We should use Redis for caching— it's super fast!' What is the primary engineering principle David's statement reflects?
David's statement focuses on performance optimization. While Redis is fast, a senior engineer would consider *all* aspects of system design, including data consistency and potential CAP theorem trade-offs. The other options represent broader architectural principles that David's comment doesn't address.
8 / 14
You are explaining your proposed architecture for a new recommendation engine to the team. You state: 'We'll use Kafka for real-time event streaming and then a Spark cluster to perform complex calculations on that data.' What does this architectural choice primarily address?
This choice emphasizes the transformation aspect. Kafka and Spark are commonly used together for real-time stream processing – transforming raw events into actionable insights. The other options represent distinct architectural concerns that aren't the primary focus of this particular combination of technologies.
9 / 14
During a standup meeting, you're discussing the design for a new feature. Mark (Senior Architect) asks: 'What's your plan to ensure we can handle peak loads without performance degradation?' You respond: 'I'm thinking of using a message queue to decouple the components.' What is the *primary* benefit Mark is seeking, based on your response?
Mark's question directly probes scalability. Using a message queue to decouple components is a common strategy *for* achieving scalability by distributing workload and preventing bottlenecks. While fault tolerance can be a secondary benefit, the core purpose here is handling peak loads efficiently – making scalability the primary focus.
10 / 14
Alex: 'Okay, so for the user authentication service, we need to support MFA. Can you elaborate on how that will integrate with our existing OAuth flow?'
This question tests your ability to understand requirements beyond just the technical term 'MFA'. It's a crucial follow-up after presenting a high-level design. The correct answer demonstrates an understanding that integration details are paramount when discussing security features like MFA and how they interact with existing systems.
11 / 14
During a Slack discussion: 'We're seeing a lot of latency spikes on the API gateway. Based on our monitoring data, it looks like requests to the microservice are taking an average of 300ms. What's a good approach to investigate this?'
The key here is to move beyond simple scaling solutions. A good response would involve deeper diagnostics to identify the root cause of the latency – using tools like tracing and profiling allows you to pinpoint bottlenecks within the microservice itself. Simply increasing resources won't solve a problem if the underlying issue isn't addressed.
12 / 14
In a PR description: 'This change implements the new user profile update functionality. We've added support for bulk updates via the API endpoint /users/{userId}. We're utilizing optimistic locking to prevent data conflicts.'
A good PR description needs to be clear and concise. This example covers the core functionality (bulk updates) and importantly, identifies the concurrency control strategy (optimistic locking). It's important to document technical choices like this for future reference and collaboration.
13 / 14
During a standup meeting: 'I'm designing the data pipeline for our new analytics dashboard. I'm considering using Apache Airflow to orchestrate the ETL process and then pushing the transformed data directly into a Snowflake data warehouse.'
This scenario tests your understanding of current data warehousing best practices. Using Airflow for orchestration and Snowflake as a target demonstrates a scalable solution. However, a robust design would also require considerations around data quality, transformation logic, monitoring, and handling large datasets – aspects that are often overlooked.
14 / 14
Sarah (Lead Engineer) comments on your PR: 'The code assumes all API responses are always successful. What happens if the external service returns an error? We need to implement proper error handling and retry mechanisms.'
This is a critical point in system design – handling failures from external dependencies. A good response would acknowledge the possibility of error responses and implement appropriate error handling, including retries with exponential backoff. Ignoring this leads to brittle systems that fail silently.
What will I learn from the "System Design Interview Language — Software Architecture Exercises" exercise?
Practice English for system design interviews: requirements clarification, back-of-the-envelope estimation, bottleneck identification vocabulary, SPOF analysis, and scaling sequencing rationale. 5 advanced exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 14 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Software Architecture exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss software architecture topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 14 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Software Architecture exercises?
See the full Software Architecture exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.