System Design Interview Language — Software Architecture Exercises

1 / 5

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 / 5

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 / 5

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 / 5

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	Near-zero (existing instance already serving traffic)
Managed LB service	Cloud-managed load balancer (AWS ALB, GCP Load Balancing) with built-in redundancy	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 / 5

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?

Scaling sequencing vocabulary — why simplicity first:

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.

Scaling option	Complexity	Application changes needed?	Cost of reversal
Vertical scaling	Low — resize instance in cloud console	None	Low — resize back down
Read replicas	Low — enable replication, update read connection string	Minimal — change read endpoint	Low
Caching layer	Medium — design invalidation strategy	Yes — add cache read/write to application code	Medium
Horizontal sharding	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."