The Solutions-Consulting System-Design Interview¶

Estimated time: 42 min read · Part: Cracking the Tier-1 Interview

The system design interview is the closest thing to an actual client engagement compressed into 45 minutes. You are given an ambiguous requirement (“design Twitter”), a whiteboard or virtual canvas, and an interviewer who will probe until they find where your knowledge ends. The candidates who perform best do not have the deepest knowledge of any single system. They have a process — a structured way to move from requirements to trade-off-aware architecture — and they apply it every time regardless of the prompt.

The Six-Step Framework¶

flowchart LR
    A["① Requirements<br/>(Functional + NFR)"] --> B["② Estimate<br/>(QPS, storage, BW)"]
    B --> C["③ High-Level Design<br/>(boxes & arrows)"]
    C --> D["④ Deep Dive<br/>(interviewer picks 1–2)"]
    D --> E["⑤ Scale<br/>(bottlenecks + fixes)"]
    E --> F["⑥ Wrap-Up<br/>(trade-offs + open Qs)"]

Step 1 — Requirements (5 min). Gather functional requirements (what the system does) and non-functional requirements (how well it does it). Never skip this step. Functional: what actions does a user take? What does the system produce? Non-functional: scale, availability, latency, consistency, durability, compliance, geo distribution.

Step 2 — Estimate (3–5 min). Back-of-envelope numbers to size the system. You need QPS (queries per second), storage, and bandwidth. These numbers constrain every technology choice that follows.

Step 3 — High-Level Design (10 min). Draw boxes and arrows. Label every component. Draw data-flow arrows with a direction. Mark read vs write paths explicitly. Do not go deep on any single component yet.

Step 4 — Deep Dive (15–20 min). The interviewer will pick one or two components to explore. Follow their lead. Go deep on whatever they signal. Common deep dives: the database schema, the caching layer, the message queue fan-out strategy, the rate limiter algorithm.

Step 5 — Scale (5 min). Identify the top two or three bottlenecks and propose fixes. Read bottleneck → read replica or cache. Write bottleneck → sharding or async queue. Single-region → geo-distribution and CDN.

Step 6 — Wrap-Up (2 min). Summarise the design, name the trade-offs you made deliberately, and list open questions you would resolve with more time. This is where the consulting differentiator lands hardest.

Non-Functional Requirements Deep Dive¶

Capacity Estimation: The Power-of-2 Cheat Sheet¶

"""Back-of-envelope capacity estimator.
Run during interviews to derive concrete numbers quickly.
"""

def estimate(
    daily_events: int,
    avg_event_bytes: int,
    retention_days: int,
    read_write_ratio: float = 10.0,   # reads per write
    peak_multiplier: float = 3.0,     # peak vs average traffic
    replication_factor: int = 3,
) -> dict:
    avg_write_qps = daily_events / 86_400
    avg_read_qps  = avg_write_qps * read_write_ratio
    peak_write_qps = avg_write_qps * peak_multiplier
    peak_read_qps  = avg_read_qps  * peak_multiplier

    raw_storage_gb   = daily_events * avg_event_bytes * retention_days / 1e9
    total_storage_gb = raw_storage_gb * replication_factor

    write_bw_mbps = peak_write_qps * avg_event_bytes * 8 / 1e6
    read_bw_mbps  = peak_read_qps  * avg_event_bytes * 8 / 1e6

    # Assume: 1 server handles ~5 000 light reads/s or ~500 heavy writes/s
    read_servers  = max(1, int(peak_read_qps  / 5_000))
    write_servers = max(1, int(peak_write_qps / 500))

    return {
        "avg_write_qps":    round(avg_write_qps, 1),
        "avg_read_qps":     round(avg_read_qps, 1),
        "peak_write_qps":   round(peak_write_qps, 1),
        "peak_read_qps":    round(peak_read_qps, 1),
        "storage_raw_gb":   round(raw_storage_gb, 1),
        "storage_total_gb": round(total_storage_gb, 1),
        "write_bw_mbps":    round(write_bw_mbps, 2),
        "read_bw_mbps":     round(read_bw_mbps, 2),
        "read_servers":     read_servers,
        "write_servers":    write_servers,
    }

# Example: analytics ingestion service, 10 M events/day, 500 bytes each, 90 day retention
result = estimate(
    daily_events=10_000_000,
    avg_event_bytes=500,
    retention_days=90,
)
for k, v in result.items():
    print(f"{k:<22}: {v}")

output avg_write_qps : 115.7 | avg_read_qps : 1157.4 | peak_write_qps : 347.2 | storage_raw_gb : 450.0 | storage_total_gb : 1350.0 | read_servers : 1 | write_servers : 1

Common Design Prompts: Templates and Key Insights¶

Full Walkthrough: URL Shortener¶

The Consulting Differentiator¶

import time

class TokenBucketRateLimiter:
    """Single-server token bucket. Each user has their own bucket.

    Distributed extension (describe verbally):
    - Store (tokens, last_refill_ts) per user in Redis as a hash.
    - Use a Lua script for atomic read-modify-write:
        local tokens, ts = redis.call('HMGET', key, 'tokens', 'ts')
        -- refill proportionally to elapsed time
        -- decrement if tokens >= 1
        -- return allow/deny
    - Lua script runs atomically on the Redis node: no race conditions.
    - Use Redis cluster with consistent hashing so each user always
      hits the same shard (no cross-shard coordination needed).
    """

    def __init__(self, capacity: int, refill_rate: float) -> None:
        """
        capacity:    max tokens (burst size)
        refill_rate: tokens per second added continuously
        """
        self.capacity = capacity
        self.refill_rate = refill_rate
        self._buckets: dict[str, tuple[float, float]] = {}
        # value: (current_tokens, last_refill_timestamp)

    def _get_bucket(self, user_id: str) -> tuple[float, float]:
        return self._buckets.get(user_id, (float(self.capacity), time.monotonic()))

    def allow(self, user_id: str) -> bool:
        tokens, last_ts = self._get_bucket(user_id)
        now = time.monotonic()
        elapsed = now - last_ts
        # Refill: add tokens proportional to elapsed time
        tokens = min(self.capacity, tokens + elapsed * self.refill_rate)
        if tokens >= 1.0:
            self._buckets[user_id] = (tokens - 1.0, now)
            return True
        else:
            self._buckets[user_id] = (tokens, now)
            return False

# Test: capacity 5, refill 1 token/sec
limiter = TokenBucketRateLimiter(capacity=5, refill_rate=1.0)
user = "alice"
# Burst: first 5 should be allowed, 6th denied
results = [limiter.allow(user) for _ in range(6)]
assert results == [True, True, True, True, True, False], results
print("Rate limiter test passed")