Interview Framework & Pattern Library

Forty Minutes on the Schema

A mid-level engineer walks into a system design interview at a Bangalore product company. The prompt: "Design Instagram."

Minute 1: Requirements. Scale, users, features. Good start.

Minute 5: Data model. Users table, posts table, follows table. Reasonable.

Minute 15: Still on data model. Now discussing indexes. Composite keys. UUID vs auto-increment for post IDs.

Minute 30: Still on schema. Foreign keys. Normalization decisions. The interviewer is nodding but checking the clock.

Minute 40: Interviewer intervenes. "Let's move to the high-level architecture."

Five minutes left for the part that actually decides the outcome: feed fan-out for 100 million followers, media pipeline, CDN, cache strategy, celebrity problem.

Debrief: "Strong data modeling. Did not get to scalability. Not ready."

The technical skills were fine. Time allocation killed the interview. I have seen this exact failure dozens of times. The framework that prevents it is what this lesson teaches.

Interview framework patterns are a 45-minute timetable for system design rounds. Requirements, APIs, high-level design, deep dive, trade-offs. When you finish this lesson, you can drive the clock, name reusable patterns, and pivot before minute thirty without panicking.

Tradeoff: Structure feels rigid in the room. Unstructured brilliance feels natural. Unstructured brilliance fails 80% of the time under a 45-minute clock.

Why Should You Care?

1. The first five minutes set the ceiling. Identify question type, gather requirements, announce your plan. One sentence of meta-awareness ("I'll spend five minutes on requirements, then move to high-level design") signals Lead-level communication.
2. Estimation is not math homework. It is a credibility signal. "100 million DAU, 10% post daily, 500 bytes per post, 5-year retention" tells the interviewer you design with numbers, not vibes.
3. Patterns are reusable ammunition. Fan-out, hot key, spike absorption. Once you name the pattern, the interviewer knows you have seen production pain before.

The train timetable is the spine. Let us learn the stops before the full walkthrough.

🟢 The Simple Version (Start Here If You're New)

The Train Journey with Five Stops

In plain words: an interview is a fixed journey with five stops. Miss a stop and you fail before the deep dive starts.

Think of a system design interview like an express train from Mumbai to Delhi. Five stops. Fixed timetable. You cannot spend two hours at Vadodara admiring the station architecture and still reach Delhi on time.

The candidate drives the train. Not the interviewer. Most interviewers will let you spend forty minutes on schema if you let them. Your job is to manage the clock.

The Six Questions Before Any Box

In plain words: six questions before any box save you from designing the wrong system for forty minutes.

Before you touch the whiteboard, ask these. Out loud. With a pen ready to write the answers.

1. Scale: How many users? DAU (daily active users)? Read/write ratio? Peak QPS (queries per second)?
2. Reliability: Can we lose data? Acceptable downtime? Idempotency (safe retries without double-charging) needs?
3. Latency: p99 (99th percentile, the slowest 1% of requests) target? Real-time or eventual OK?
4. Scope: What is in? What is explicitly out?
5. Constraints: Existing tech? Team size? Regulatory limits?
6. Data: Shape, size, retention, access patterns?

For "Design a notification system at Swiggy": "80 lakh DAU" and "internal admin tool for 50 users" are different systems. Ask.

After each answer, synthesize: "So because transactional notifications cannot be lost, I'll design for at-least-once delivery with idempotent consumers."

Tradeoff: Six questions can feel slow. Jumping to Kafka in minute one feels fast. Fast in the wrong direction fails the interview.

You have the timetable and the six questions. Next we walk each phase with scripts you can say out loud.

🟡 Going Deeper: The Full Framework

Phase 1: Requirements (Minutes 0 to 5)

Separate functional from non-functional. Functional is what the system does. Non-functional is how well it must do it.

Functional example for BookMyShow: search movies, select seats, hold seats for 7 minutes, process payment, send ticket.

Non-functional: 5 million ticket purchases on a blockbuster opening weekend, p99 seat selection under 200ms, no double-booking of the same seat, 99.95% uptime.

State what is out of scope: "I'll exclude the video streaming pipeline and focus on ticket booking. Fair?"

This one sentence saves fifteen minutes of derailment.

Phase 2: API and Entities (Minutes 5 to 10)

Sketch 3 to 5 core APIs. Name the entities they touch.

POST /v1/shorten     { long_url } → { short_url }
GET  /{short_code}   → 302 redirect
GET  /v1/stats/{id}  → { clicks, countries }

Entities: URL mapping, click event, optional user. Relationships: one URL has many click events.

Do not normalize into seventeen tables. Interviewers want to see you know the nouns, not that you are a DBA.

Phase 3: Back-of-Envelope Estimation (Minutes 8 to 12, woven in)

Estimation proves you think in numbers. Rough is fine. Wrong by 10x is not.

The cheatsheet formulas:

Useful constants to memorize:

• Seconds per day: 86,400 (round to 100K for mental math: divide by 100,000)
• 1 million requests/day ≈ 12 QPS average
• 1 billion requests/day ≈ 12,000 QPS average
• Text tweet/post: ~300 bytes metadata + content
• Photo metadata: ~500 bytes in DB (bytes in S3)
• IPv4 address: 4 bytes
• UUID string: 36 bytes

India-scale worked example (URL shortener):

• 1 crore URLs created per month → 1Cr / (30 × 86400) ≈ 4 writes/sec
• 10 crore redirects per month → ≈ 38 reads/sec average
• Peak viral link: 10,000 reads/sec on one URL (this drives cache design, not the average)
• 5-year storage: 6 crore URLs × 500 bytes ≈ 30 GB (fits one Postgres)

Say these numbers out loud. Watch the interviewer's body language relax. You are now designing, not guessing.

Phase 4: High-Level Design (Minutes 10 to 25)

Draw the request path left to right. Narrate a single user action through the system.

For read-heavy systems: client → DNS → load balancer → API → cache → database (on miss) → response.

For write-heavy pipelines: client → API → queue → workers → database.

Label sync vs async. Label what is hot path vs background.

Flag your deep dive early: "The interesting part here is feed fan-out. I'll sketch the rest quickly and come back to fan-out in detail."

Phase 5: Deep Dive (Minutes 25 to 40)

Pick 2 or 3 components. Not fifteen. Go deep on the bottleneck.

Junior deep dive: "The database stores posts in a posts table."

Senior deep dive: "For users with under 1 million followers, fan-out on write: when someone posts, push post ID to each follower's feed cache. For celebrities above the threshold, fan-out on read: merge celebrity posts at read time. Threshold needs a background job because follower counts change."

The progression shows where the hard problems live.

Phase 6: Trade-offs and Evolution (Minutes 40 to 45)

End with honesty:

• "Alternatively, we could fan-out on read only. Simpler writes, slower reads. I chose hybrid because read latency is the NFR."
• "At 10x scale, the first thing that breaks is..."
• "If the interviewer constraint changes to multi-region, I would add..."

The phased script is the classroom version. The war room is what separates senior from lead in the room.

🔴 Architect's Corner / War Room

Driving the Conversation: Three Techniques

Signposting: Announce phases and time boundaries. "I'll spend three minutes on APIs, then draw the high-level flow. Does that work?"

Active pivoting: Notice when you are drifting. "I could keep going on index design, but I want to cover caching before we run out of time. Continue here or move on?"

Flagging for later: Park tangents without losing them. "Message deduplication needs careful thought. I'm noting it for the deep dive."

If you flag it, you must come back. Saying "we'll cover that later" and never returning is worse than not flagging.

Question Type Identification (First 60 Seconds)

System design questions come in three flavors. Misidentify the flavor and you answer the wrong exam.

Weaponized clarifying question for vague prompts: "Are we designing the high-level product with user flows, or the low-level delivery infrastructure?"

One sentence. Three signals. You identified the flavor, showed both layers exist, and handed the interviewer a menu.

Estimation Drill: Work These Before Interview Week

Practice these until you can say them in under 90 seconds each.

Drill 1: Design WhatsApp (simplified messaging)

• 500 million users in India, 200 million DAU (round numbers for mental math)
• Each DAU sends 50 messages/day → 200M × 50 = 10 billion messages/day
• 10B / 100,000 ≈ 100,000 QPS average (divide by 100K for speed)
• Peak 3× → 300,000 QPS (interview round: "a few lakh QPS at peak")
• Message size ~500 bytes metadata → 10B × 500B = 5 TB/day raw (you will partition, not store forever)

Drill 2: Design BookMyShow (ticket booking)

• Big release: 2 million tickets in 2 hours → 2M / 7200 ≈ 280 writes/sec average during window
• Peak minute might be 10× → 2,800 writes/sec (seat holds are write-heavy, short burst)
• Storage: 10 years of bookings, 100 bytes each, 50 million bookings/year → 50GB/year, manageable in SQL

Drill 3: Design YouTube view counter (heavy hitter preview)

• 1 billion views/day globally, India 200 million views/day
• 200M / 100,000 = 2,000 QPS average view increments
• Exact counting at this scale is hard. Mention approximate counting (HyperLogLog, sharded counters). This preview connects to Phase 11 heavy hitters.

If your estimate is wrong by 5×, that is fine. If you never estimate, the interviewer assumes you cannot.

The Pattern Library (Memorize These Names)

Fan-out (write vs read vs hybrid): Producer event must reach many consumers. Write path: push to all followers on post (Instagram). Read path: assemble feed on read (Twitter early architecture). Hybrid: push for normal users, pull for celebrities.

Hot key: One key gets disproportionate traffic. IPL final score in Redis. Viral bit.ly link. Fix: local in-process cache in front of Redis, read replicas for that key, or split the key into shards (score:match1:shard3).

Spike absorption: Burst traffic exceeds steady capacity. Tatkal at 10 AM. Big Billion Days first minute. Fix: queue (Kafka, SQS), waiting room, rate limit the accept path, pre-warm cache.

Consistent hashing: Distribute keys across nodes with minimal reshuffle on add/remove. Distributed cache, sharding, CDN origin selection.

Cache-aside: App checks cache, on miss reads DB, writes cache. Simple. Stampede risk on hot keys.

CQRS: Separate read and write models. Write to OLTP, project to read-optimized store. Pays complexity for read scale.

Idempotency key: Client sends Idempotency-Key: uuid. Server stores result keyed by that UUID. Retries return same response without double charge. Non-negotiable for payments.

Split brain / quorum: Distributed systems need majority agreement. Cassandra QUORUM, Raft, ZooKeeper. Interview depth for infra questions.

Bloom filter: Probabilistic "definitely not in set" check. Web crawler visited URL dedup. Reduces DB lookups.

Leader election: One writer at a time. Scheduler, payment reconciliation job. Redis Redlock, Raft, database advisory lock.

When you name a pattern, explain the force that creates it: "Viral URL creates a hot key on the redirect path, so I add a local LRU in front of Redis."

When the Interviewer Changes Requirements

At minute 30: "Now assume 100 crore users instead of 1 crore."

Do not restart. Do not panic.

"At 100 crore users, three things break first: the fan-out write volume for celebrity posts, the notification queue partition count, and the media storage egress bill. The core architecture stays. We add sharding by user ID, hybrid fan-out, and multi-region object storage."

This shows scale thinking. "Redesign from scratch" shows panic.

Senior vs Architect Signals

Senior (8+ YoE): Proactively names the hardest sub-problem. Trade-offs explicit. Drives time. Handles constraint changes.

Architect (12+ YoE): Adds operational reality: deployment, monitoring, rollback, team ownership, cost. Says "I would defer Kafka until event volume exceeds X." May push back on contradictory requirements.

Tradeoff: Architect answers sound less flashy. "Start simpler" does not impress on a whiteboard. It impresses in the debrief.

Patterns are abstract until you see them on Indian traffic. These examples ground the framework.

How India-Scale Systems Do It

Flipkart Big Billion Days: Spike absorption pattern everywhere. Waiting room queue before sale. Inventory reservation with optimistic locking. CDN for static assets pre-warmed days ahead. Kafka or internal bus for order events after the accept path survives the spike.

Hotstar IPL: Hot key pattern on live match score and concurrent viewer count. Fan-out on read for recommendations. CDN for video segments. Estimation matters: 25M concurrent viewers changes every box size.

IRCTC tatkal: Spike plus strong consistency on seat inventory. Queue token pattern (fairness). You cannot eventual-consistency a contested seat. Requirements phase must surface this.

PhonePe UPI: Idempotency key pattern on every payment API. At-least-once delivery from clients on flaky mobile networks. Ledger stays CP (Postgres). Notifications can be AP.

Swiggy dinner rush: Read-heavy restaurant listing with cache-aside. Write spike on order placement absorbed by queue to downstream kitchen and rider systems. Estimation: orders per minute per city drives partition count.

Dream11 IPL deadline: Spike absorption plus hot key on leaderboard. Last 90 minutes before lock: 5 crore team submissions. Queue between "submit" accept and downstream validation. Sorted set leaderboard for live rank during match (Redis pattern, connects to tech deep dive lesson).

Zerodha market open: Latency-sensitive reads (portfolio) vs write spike (orders at 9:15 AM). Different paths. Portfolio read can cache with short TTL. Order placement needs CP database, not eventual cache.

The Decision Matrix / Tradeoff Table

The matrix is the cheat sheet. These mistakes are what I still debrief every week.

Common Mistakes

1. "I'll use Kafka" before requirements. Technology before requirements is the most common fail I see. The fix is six questions first. Always.

2. Schema rabbit hole. Thirty minutes on indexes means zero minutes on fan-out. Sketch entities in five minutes. Move on.

3. No synthesis after clarifying questions. Asking ten questions without saying "so because of that, I will..." looks like a checklist, not thinking.

4. Covering everything shallowly. Fifteen components with two sentences each loses to five components with one deep dive. Interviewers remember depth.

5. Getting defensive on failure probes. "What if Redis dies?" is not an attack. It is an invitation. Know the failure mode of every box you drew.

6. Ignoring question type. Spending twenty minutes on GeoHash internals when asked "Design Uber" (breadth) fails even if GeoHash knowledge is perfect.

7. No explicit trade-offs. One correct answer with no alternatives sounds inexperienced. Real engineers choose between bad options.

🧠 Key Takeaways

• 45-minute framework: 5 min requirements, 5 min API/entities, 15 min HLD, 15 min deep dive, 5 min trade-offs.
• You drive the clock. Signpost phases. Pivot when drifting. Flag tangents for later.
• Estimation cheatsheet: DAU → daily actions → /86,400 for QPS → × peak multiplier → bytes for storage.
• Name patterns. Fan-out, hot key, spike, idempotency. Pattern name plus force equals senior signal.
• Question type matters. Product wants breadth. Infra wants depth. OOD wants classes, not load balancers.
• Constraint changes test adaptability. Identify what breaks. Do not restart.
• End with alternatives. "I chose X over Y because..." is more impressive than perfection.

Think About It

1. You are fifteen minutes into designing a rate limiter for Razorpay's payment API. You are deep in Redis Lua scripts. You still have not covered distributed rate limiting across API pods or merchant-facing rate limit headers. Write the exact sentence you would say to pivot.

2. "Design Twitter" vs "Design the timeline service." How does your first sixty seconds differ? What clarifying question do you ask?

3. A junior spends twenty minutes drawing a perfect ER diagram for Swiggy. A senior spends eight minutes on requirements and estimation, then draws five boxes and goes deep on order assignment. Who passes? Why?

Further Reading

• Gaurav Sen: System Design Interview framework. Watch one product design and one infra design. Note time allocation, not just content.
• Google SRE Book: Load Balancing at the Frontend. Useful for discussing global traffic and CDN in senior loops.
• Designing Data-Intensive Applications, Ch. 1. Reliable, scalable, maintainable. The three words interviewers grade against.
• ByteByteGo: System Design Interview templates. Good for pattern names and estimation practice. Adapt with your own war stories.
• Alex Xu's System Design Interview (Vol 1). Structured walkthroughs for classic problems. Use as drill material, not gospel.