# Interview Framework

> **How to approach a system design interview** — A step-by-step framework for SDE-3 / Senior Software Engineer interviews

***

## Overview

System design interviews evaluate your ability to **clarify ambiguity**, **reason about scale**, **make trade-offs**, and **design for failure**. This framework gives you a repeatable structure so you spend time on high-value discussion instead of figuring out what to do next.

**Typical duration**: 45–60 minutes\
**Your goals**: Show structured thinking, ask the right questions, drive the conversation, and demonstrate senior-level judgment (trade-offs, cost, operations, resilience).

***

## The Seven Phases

| Phase                           | Time      | Focus                                                |
| ------------------------------- | --------- | ---------------------------------------------------- |
| 1. Clarify requirements         | 5–10 min  | Functional + non-functional; scope and constraints   |
| 2. Estimate scale               | 5 min     | QPS, storage, bandwidth; back-of-envelope            |
| 3. High-level architecture      | 10–15 min | Components, data flow, boundaries                    |
| 4. Identify bottlenecks         | 5 min     | Where the system will break or slow down             |
| 5. Discuss trade-offs           | 5 min     | Consistency vs availability, latency vs cost, etc.   |
| 6. Deep dive into components    | 15–20 min | 1–2 components in detail (APIs, data model, scaling) |
| 7. Scaling and failure handling | 5–10 min  | Horizontal scaling, failover, degradation            |

***

## Phase 1: Clarify Requirements

**Why it matters**: Jumping into boxes and arrows before understanding the problem is the most common mistake. Senior engineers align on scope first.

### Functional requirements

* **Core features**: What are the 3–5 must-have features?
* **Users**: Who uses the system (B2C, B2B, internal)?
* **Critical user journeys**: e.g. “User shortens URL → later opens short URL → gets redirected.”
* **Out of scope (for now)**: Explicitly deprioritize (e.g. “No custom aliases in v1”).

**Questions to ask**:

* “What’s in scope for this discussion—MVP or full product?”
* “Who are the main users and what’s the most important flow?”
* “Are there any features we should explicitly leave out?”

### Non-functional requirements

Use a simple checklist so you don’t forget dimensions:

| Dimension        | What to clarify                                               |
| ---------------- | ------------------------------------------------------------- |
| **Performance**  | Latency (e.g. P99 < 200 ms), throughput (QPS), tail latency   |
| **Availability** | Uptime target (e.g. 99.9%), planned maintenance, multi-region |
| **Scalability**  | Growth (users, data, traffic), peak vs average (e.g. 3×)      |
| **Consistency**  | Strong vs eventual; read-after-write requirements             |
| **Durability**   | Can we lose data? RPO/RTO if applicable                       |
| **Security**     | Auth, PII, compliance (GDPR, etc.)                            |
| **Cost**         | Any rough budget or “optimize for cost” constraint?           |

**Example (URL shortener)**:

* “Redirect latency: P99 < 100 ms.”
* “Availability: 99.99%.”
* “We can accept eventual consistency for redirects; strong consistency for create.”
* “URLs must not be lost once created.”

### Output of this phase

* Short list of **must-have** vs **nice-to-have** features.
* Clear **non-functional targets** (latency, availability, scale, consistency).
* Agreement on **scope** so you don’t over- or under-design.

***

## Phase 2: Estimate Scale

**Why it matters**: Scale drives technology choices (single DB vs sharding, cache vs no cache, sync vs async). Show you think in numbers.

### What to estimate

1. **Traffic**
   * DAU/MAU or requests per day/month.
   * Reads vs writes ratio (e.g. 100:1 for URL shortener).
   * Peak QPS (e.g. 3× average).
2. **Storage**
   * Record size and retention (e.g. 5 years).
   * Total size and growth rate.
   * Replication factor (e.g. 3×).
3. **Bandwidth**
   * In/out per request and total (optional for first pass).

### How to present

* State assumptions clearly: “Assume 100M new URLs per month, 100:1 read:write.”
* Do simple math on the whiteboard:
  * Writes: 100M / (30 × 86,400) ≈ 40/s → peak \~120/s.
  * Reads: 40 × 100 = 4,000/s → peak \~12,000/s.
* Round to one significant figure for discussion: “\~100 writes/s, \~10K reads/s.”

### Output

* **Read QPS** and **write QPS** (or equivalent).
* **Total storage** and **storage per node** if relevant.
* These numbers justify caching, sharding, and replication later.

***

## Phase 3: High-Level Architecture

**Why it matters**: This is the “picture” the rest of the interview builds on. Keep it simple first; add detail in deep dives.

### Components to consider

* **Clients** (web, mobile, API consumers).
* **Edge / CDN** (static assets, sometimes redirects).
* **Load balancer(s)**.
* **API / application servers** (stateless).
* **Caches** (e.g. Redis).
* **Databases** (primary + replicas, or sharded).
* **Message queues** (async jobs, events).
* **External services** (payments, notifications).

### How to draw

1. Draw **client → LB → app servers → cache → DB** as a first cut.
2. Add **queues** and **workers** if you have async or background work.
3. Label **read vs write path** if they differ.
4. Add **replicas** or **shards** only after you’ve stated the need (e.g. “We’ll need read replicas for 10K reads/s”).

### Data flow

* Describe in one sentence: “User hits short URL → LB → app server → cache; on miss, DB → cache → redirect.”
* Mention **sync vs async**: “Create short URL is synchronous; click analytics are sent to a queue and processed asynchronously.”

### Output

* A **single diagram** with 5–10 boxes and clear flow.
* A **one-paragraph** narrative: “Traffic hits the LB, then stateless API servers. We cache hot URLs; on miss we hit the DB and backfill cache. Writes go to the primary; we’ll add read replicas for scale.”

***

## Phase 4: Identify Bottlenecks

**Why it matters**: Shows you think about limits, not just “happy path.” Senior engineers anticipate failure modes.

### Typical bottlenecks

| Component     | Risk                               | Mitigation (to discuss in Phase 7)                          |
| ------------- | ---------------------------------- | ----------------------------------------------------------- |
| Single DB     | Writes and reads saturate one node | Sharding, read replicas                                     |
| Cache         | Stampede on miss, or cache down    | Cache-aside + TTL, fallback to DB; consider single-flighter |
| API servers   | CPU or memory under spike          | Horizontal scaling, rate limiting                           |
| Message queue | Consumer lag, queue depth          | More consumers, backpressure, DLQ                           |
| External API  | Latency or rate limits             | Timeouts, circuit breaker, cache, queue                     |

### How to present

* “The main bottlenecks I see: (1) DB write capacity if we grow beyond one node, (2) cache stampede on a viral link, (3) DB as single point of failure.”
* Then briefly: “I’d address (1) with sharding, (2) with TTL and maybe request coalescing, (3) with failover and replicas.”

### Output

* **2–4 concrete bottlenecks** and **one-line mitigations**. You’ll detail them in Phase 6–7.

***

## Phase 5: Discuss Trade-offs

**Why it matters**: SDE-3 is expected to articulate *why* a design is chosen, not just *what* it is.

### Common trade-offs

* **Consistency vs availability**: CP vs AP; strong vs eventual.
* **Latency vs consistency**: Synchronous replication vs async.
* **Cost vs performance**: More cache vs more DB; more replicas vs lower durability.
* **Complexity vs flexibility**: Monolith vs microservices; single DB vs polyglot persistence.
* **Operational complexity**: Self-managed vs managed services (e.g. RDS vs self-hosted Postgres).

### How to present

* “For redirects we’ll use eventual consistency and cache heavily—low latency and high availability matter more than perfect freshness. For creating a short URL we’ll want strong consistency so we don’t hand out duplicates.”
* “We could use 2PC for cross-service transactions, but that’s blocking and complex; I’d prefer a saga with compensating actions and idempotent steps.”

### Output

* **2–3 explicit trade-offs** with a clear “we choose X because Y” statement.

***

## Phase 6: Deep Dive into Components

**Why it matters**: Interviewers want to see depth in at least one or two areas: API design, data model, or a specific component (cache, queue, DB).

### What to prepare

1. **API design**
   * REST or RPC; idempotency for writes (e.g. idempotency key).
   * Key endpoints: create short URL, redirect, optional analytics.
   * Status codes and errors (rate limit, not found, conflict).
2. **Data model**
   * Main entities and relationships.
   * Schema (tables or documents): e.g. `short_code` (PK), `long_url`, `user_id`, `created_at`.
   * Indexes: by `short_code` (lookup), by `user_id` (list user’s URLs).
   * Sharding key if you shard (e.g. `short_code`).
3. **One or two components in detail**
   * **Cache**: Strategy (cache-aside), TTL, eviction (LRU), key format, stampede mitigation.
   * **Database**: Sharding strategy (hash vs range), replication (sync vs async), failover.
   * **Queue**: Use case (analytics, notifications), at-least-once vs exactly-once, consumer scaling.

### How to run the deep dive

* “I’ll go deeper on the cache and the database.”
* For cache: “We use cache-aside. Key is `url:{short_code}`. TTL 24 hours. On miss we load from DB and backfill. We use LRU when memory is full.”
* For DB: “We shard by `hash(short_code) % N` so lookups are single-shard. We use read replicas for read scaling; writes go to primary.”

### Output

* **Concrete API** (method, path, body, idempotency).
* **Schema + indexes + sharding key**.
* **Clear behavior** of 1–2 components (cache, DB, or queue).

***

## Phase 7: Scaling and Failure Handling

**Why it matters**: Production systems scale and fail; you need to show you think about both.

### Scaling

* **Horizontal**: More app servers behind LB; more DB shards; more cache nodes; more consumers.
* **Vertical**: Bigger DB/cache instances when it’s simpler (e.g. early stage).
* **Read scaling**: Read replicas, cache, CDN.
* **Write scaling**: Sharding, async writes (queue), batching.

State clearly: “We scale reads with replicas and cache; we scale writes by sharding when we outgrow one DB.”

### Failure handling

* **DB primary down**: Failover to replica; promote replica to primary; use replication.
* **Cache down**: Fall back to DB; accept higher latency; optional stale cache from another region.
* **App server down**: Stateless; LB stops sending traffic; no session state lost.
* **Queue backlog**: Scale consumers; backpressure; DLQ for poison messages; alert on lag.

### Degradation

* “If the recommendation service is down, we show a default list instead of failing the page.”
* “If DB is slow, we might serve stale from cache and surface a short delay message.”

### Output

* **Scaling strategy** in one or two sentences (read vs write, when to shard).
* **2–3 failure scenarios** with clear mitigations (failover, fallback, degradation).

***

## Quick Reference: What to Say When

| Situation                | Suggested response                                                               |
| ------------------------ | -------------------------------------------------------------------------------- |
| Unclear scope            | “For this exercise, should we focus on MVP or include analytics/custom aliases?” |
| Unclear scale            | “What order of magnitude are we designing for—e.g. 1K vs 100K vs 1M DAU?”        |
| After drawing HLD        | “The main bottlenecks I see are … I’d address them by …”                         |
| Choosing technology      | “I’d use X because … The trade-off is …”                                         |
| Asked “what if X fails?” | “We’d … (failover / fallback / degrade). The impact would be …”                  |
| Running out of time      | “If we had more time, I’d go deeper on … and add …”                              |

***

## Common Mistakes to Avoid

1. **Designing before clarifying** — Always do requirements and scale first.
2. **Over-complicating the first diagram** — Start with 5–7 boxes; add detail when asked.
3. **Ignoring failure** — Always mention at least one failure mode and mitigation.
4. **No trade-offs** — Explicitly state at least one “we choose A over B because …”.
5. **No numbers** — Do at least rough QPS and storage so your choices are justified.
6. **Monologue** — Ask 2–3 clarifying questions and confirm scope before drawing.

***

## Quick Revision (Interview Day)

* **Clarify**: Functional + non-functional; scope; 2–3 questions.
* **Estimate**: QPS (read/write), storage, state assumptions.
* **HLD**: Client → LB → app → cache → DB (+ queues if needed); one-sentence flow.
* **Bottlenecks**: 2–4 with one-line mitigations.
* **Trade-offs**: 2–3 “we choose X because Y.”
* **Deep dive**: API + schema + 1–2 components (cache, DB, or queue).
* **Scaling**: Horizontal, read vs write, when to shard.
* **Failure**: Failover, fallback, graceful degradation.

Use this framework to drive the interview and to demonstrate structured, senior-level thinking.