Listening to System Design Discussions: Vocabulary and Comprehension
5 exercises — identifying design constraints, understanding trade-off reasoning, catching scale figures, recognising approach changes, and the 'we considered X but' pattern in system design discussions.
0 / 5 completed
1 / 5
You are listening to a system design discussion. The speaker says: 'We have about 50 million users, but only around 2% are active at any given time. Writes are rare — maybe 1 in 100 operations. Read latency must be under 50ms at the 99th percentile. And we need to run in three AWS regions.' Which of these is NOT a design constraint mentioned?
Identifying design constraints: Listen for numbers, SLAs, and infrastructure requirements. The speaker mentioned: active users (~1M), write ratio (1%), latency SLA (50ms P99), and multi-region (3 regions). OAuth 2.0 was never mentioned — it is a distractor. In real system design discussions, distinguish constraints (given requirements) from implementation decisions (your choices).
2 / 5
A speaker in a design discussion says: 'We went with eventual consistency over strong consistency here. Yes, users might see slightly stale data for a few seconds, but the write throughput gains are worth it for our use case.' What reasoning pattern is the speaker using?
Trade-off reasoning: Listen for the pattern: 'We chose X over Y. Yes, X has cost [Z], but the benefit [W] is worth it for our use case.' This is deliberate architectural trade-off language. 'Yes... but...' signals the speaker is acknowledging the downside explicitly — a sign of experienced system design communication.
3 / 5
During a system design talk, the presenter says: 'We're targeting 10,000 writes per second at peak, with bursts up to 3×. Average payload size is 2KB.' What is the peak burst write throughput in megabytes per second?
Catching and calculating scale figures: Peak writes = 10,000 × 3 = 30,000 writes/sec. At 2KB each: 30,000 × 2KB = 60,000KB/s = ~60MB/s. Listening to system design talks requires both hearing numbers accurately and doing quick mental arithmetic to assess feasibility of proposed solutions.
4 / 5
A speaker says: 'Initially we thought we'd use a single PostgreSQL instance with read replicas. But as we dug into the write amplification issue, we pivoted to a sharded approach.' What does 'pivoted' signal here?
Recognising approach changes: 'Initially... but... pivoted' is a classic narrative structure for explaining why a design changed. 'Pivoted' = changed direction significantly. Listening for 'initially/originally/at first... but/however/then we realised' patterns helps you follow the evolution of a design and understand the reasoning behind the final choice.
5 / 5
A system design speaker says: 'We considered Redis for this, but the memory cost at our data volume would have been prohibitive — we're talking about 40TB of data. So we went with a hybrid approach: hot data in Redis, cold data in S3 with a lazy-loading tier.' What does 'we considered X but' signal?
'We considered X but' pattern: This phrase signals that X was seriously evaluated (not dismissed) but rejected for a concrete reason. Here the reason is quantified: 40TB in Redis would cost too much. The alternative addresses the constraint (Redis for hot data only = smaller footprint, S3 for cold). This pattern is a signal of thorough design work — alternatives were considered, not just the chosen path.