The 45-Minute HLD Framework: How to Ace Any System Design Interview

Most engineers who fail the HLD interview round don't fail because they can't design systems. They fail because they spend 22 minutes on requirements and run out of time before the deep dive — the phase worth 35% of the grade. The HLD interview framework isn't about knowing more. It's about allocating 45 minutes so the interview surfaces your actual depth, not your tendency to over-clarify.

This post gives you the minute-by-minute structure, the grading weights interviewers actually use, and the company-specific signals that separate passing candidates at Razorpay, Swiggy, Flipkart, Coupang, and Stripe from candidates who produced the exact same diagram and still didn't get an offer.

What Interviewers Actually Grade (Most Candidates Don't Know This)

Before you can manage 45 minutes intelligently, you need to understand how those minutes get scored. Based on rubrics reported by interviewers at product companies — and validated against published rubric frameworks from engineering hiring blogs — the grading weights look like this:

HLD Interview Grading Weights

| Phase | Weight | What It Tests | |---|---|---| | Requirements gathering | 15% | Did you ask the right questions and scope correctly? | | High-level architecture | 25% | Can you break a complex problem into justified components? | | Detailed design (deep dive) | 35% | Can you go deep on the hard parts and reason about internals? | | Trade-offs and bottlenecks | 25% | Do you know what breaks and why your choices cost something? |

The deep dive plus trade-offs is 60% of your score. Most engineers spend 60% of their prep time on requirements frameworks and generic architecture templates. That's a preparation inversion — polishing the least-weighted phases while under-developing the most weighted ones.

This matters because it reshapes how you use the clock. You're not just fitting content into slots — you're front-loading the cheaper phases to buy time for the expensive ones.

The HLD Interview Framework: Minute-by-Minute

Here is the exact time allocation. Use it as a metronome. Announce each transition out loud — that demonstration of time awareness signals the structured communication that interviewers score separately from technical content.

Phase 1 — Requirements (0–5 min, 15% of grade)

Five minutes. Not eight, not twelve. Five.

Your goal here is not comprehensiveness — it's the 3 questions that change the architecture. Most clarifying questions candidates ask don't change the design at all ("Should we support mobile?"). The ones that matter expose scale, consistency requirements, and the critical path.

The three architecture-changing questions for any HLD problem:

1. "What's the scale — DAU and peak QPS?" This determines whether you need horizontal scaling and what tier of caching is mandatory.
2. "Is this read-heavy or write-heavy, and what's the latency SLA on the critical path?" This drives your database choice and whether you're optimizing for throughput or response time.
3. "Do we need strong consistency, or is eventual consistency acceptable for [specific feature]?" This single question changes your entire data replication strategy.

Non-functional requirements by problem domain:

• Payment systems (Razorpay, Stripe) → Exactly-once processing, idempotency, ACID, zero data loss on failures, reconciliation correctness
• Food delivery (Swiggy, DoorDash) → Sub-2s dispatch latency, at-least-once delivery event semantics, driver location freshness under 5s
• E-commerce (Flipkart, Coupang, Walmart) → Flash sale concurrency (inventory atomicity), catalog search sub-100ms, eventual consistency acceptable on recommendations
• Social/feed systems → Read-heavy (fanout strategy matters), P99 < 500ms, eventual consistency acceptable

State your functional requirements in 3–5 bullet points, non-functionals in 2–3, then say: "I'm going to move to estimation now — any constraints I've missed?" That sentence captures the remaining 90 seconds and gives the interviewer a clean handoff.

Phase 2 — Capacity Estimation (5–8 min)

Three minutes. Back-of-envelope. You need to be in the right order of magnitude — exact numbers don't matter, but the conclusions from the numbers matter enormously because they justify your component choices.

Peak QPS  = (Daily_Requests / 86400) × Peak_Factor (2–5×)
Storage/y = Daily_Writes × Bytes_per_write × 365

What the numbers should tell you:

• QPS > 10K → horizontal scaling + load balancer, likely sharding
• Storage > 1TB/year → object store or distributed storage
• Read:write > 10:1 → aggressive caching is mandatory, not optional
• Latency SLA < 100ms → in-memory cache in the hot path, no cold reads

Worked example — food delivery dispatch (Swiggy-scale):

• 5M DAU, ~2 orders/user/week → ~1.4M orders/day → ~16 orders/sec baseline, ~80 orders/sec peak
• Each order event stream: ~100 bytes × 80/sec = 8KB/sec — trivially small
• But driver location updates: 1M active drivers × 1 update/5s = 200K location writes/sec
• Conclusion: the location service is the actual scale bottleneck, not the order service. This changes which component you deep-dive.

That last sentence — identifying where the scale lives, not just reporting the numbers — is what earns points in estimation.

Phase 3 — High-Level Design + API (8–22 min, 25% of grade)

Fourteen minutes. Draw the system. Start simple, add only what you can justify.

The baseline template (adapt, don't memorize):

Client → CDN (if media-heavy or globally distributed)
       → Load Balancer (Layer 7, sticky sessions if stateful)
       → Application Servers (stateless, horizontally scaled)
       → Cache (Redis) — hot reads, session state
       → Primary DB — reads via replica, writes to primary
       → Message Queue (Kafka) — async processing, event sourcing
       → Background Workers — notifications, analytics, reconciliation

The rule: every component you draw must be justifiable from your requirements and estimation. Don't add Kafka because Kafka is impressive. Add Kafka when you said peak QPS is 80K/sec and synchronous DB writes can't absorb that spike without queue-based buffering.

API design in HLD: You need the 2–3 critical endpoints defined before you deep-dive. Not the full API surface — just enough to clarify the interface contract. For a food delivery system:

POST /orders                    → creates order, returns order_id
GET  /orders/{order_id}/status  → returns current state machine position
POST /drivers/{driver_id}/location → real-time location update (high-frequency)

Name the auth mechanism (Authorization: Bearer <token>), note pagination on list endpoints, and move on. Full API design belongs in a separate LLD round — here it anchors your data flow.

Data model: State the primary entities and the field that drives partitioning. For orders: order_id (partition key), user_id, driver_id, status, created_at. This signals you've thought about access patterns, which is what determines schema maturity.

After the diagram, do a quick verbal walkthrough of the happy-path request: "A user places an order → hits the Order Service via API Gateway → writes to Postgres primary → publishes an OrderCreated event to Kafka → the Dispatch Service consumes it and runs the matching algorithm → pushes a notification to the driver." One pass, thirty seconds, proves your diagram is internally consistent.

Phase 4 — Deep Dive (22–38 min, 35% of grade)

Sixteen minutes. This is where the interview is actually decided.

Pick the hardest or highest-risk component in your system — not the most interesting one to you, but the one where the most things can go wrong. Then go one level deeper than most candidates would. Not box-and-arrow — internals: data structures, failure modes, concurrency handling, edge cases.

How to pick your deep dive component:

• What's the hardest constraint to meet from non-functionals?
• What component, if it fails, causes cascading failures?
• What did you hand-wave in Phase 3 with "and then it writes to the DB"?

Deep dive examples by company context:

Razorpay/Stripe (payments): The idempotency layer. How do you prevent double-charges when a client retries after a timeout? A timeout is an unknown, not a failure — the payment may have succeeded or failed, and you can't know without querying the gateway's status API. The correct design: every payment request carries a client-generated idempotency key. Your payment service checks a Redis idempotency store (TTL 24h) before forwarding to the gateway. If the key exists and status is pending, return the cached response without re-forwarding. If success or failed, return that result. The double-charge prevention is in this Redis check, not in the gateway.

Swiggy (food delivery): Driver matching under concurrency. You have 200K active drivers and need to assign the best one within 2 seconds. Redis GEO stores all online driver locations. On order creation, run GEORADIUS to find all drivers within 3km. Score them: distance (60% weight), acceptance rate (30%), current load (10%). Top scorer gets a push notification. The concurrency problem: two orders might simultaneously score the same driver first. Solution: Redis SETNX with a 10-second TTL as a distributed soft lock. If the lock exists when your second order tries to assign, drop to the second-ranked driver. If the driver doesn't accept within 30 seconds, release the lock via TTL expiry and re-run the algorithm.

Flipkart/Coupang (flash sales): Inventory atomicity. 1M users click "Buy" simultaneously for 500 units. The failure mode: two requests both read available_qty = 1, both succeed the check, both decrement — you've sold the same unit twice. The solution that actually works at scale: don't read-then-write in application code. Use Redis DECR with a floor check (Lua script for atomicity) for the hot reservation counter, then reconcile with your Postgres source of truth asynchronously. The Redis counter is your availability signal; the Postgres row is your financial record. They can disagree temporarily — that's fine — but the Redis decrement is atomic, so you never oversell.

Phase 5 — Trade-offs (38–45 min, 25% of grade)

Seven minutes. If the interviewer cuts you off, still bring it up: "Can I take 2 minutes on the key trade-offs before we close?" No interviewer will say no.

The trade-off formula that works: "I chose X over Y because [requirement-specific reason]. The cost is [concrete downside]. I'd mitigate it by [specific mechanism], and I'd revisit this decision if [named condition that changes the calculus]."

Trade-offs that matter for product company contexts:

| Decision | The cost you must name | When to revisit | |---|---|---| | Kafka for async dispatch | Introduces eventual consistency — order status may lag by 1–3 seconds | If SLA requires < 500ms status update, switch to sync + read replica | | Redis for driver location | In-memory = expensive at 1M drivers × 100 bytes = ~100MB/node, not free | If driver count exceeds 10M, evaluate geospatial DB (PostGIS, MongoDB Atlas) | | Cassandra for order history | No JOIN queries — reporting needs denormalized tables or a separate OLAP store | If business requires cross-entity reports with ad-hoc joins, keep Postgres + Redshift for analytics | | Saga pattern for distributed transactions | Compensating transactions add code complexity and require idempotent rollbacks | If you can colocate services, 2PC on a single DB is simpler and more correct | | Write-through cache for hot items | Every write goes to cache AND DB synchronously — higher write latency | If write volume spikes above 10K/sec, shift to cache-aside with TTL to decouple |

One more move that high-performing candidates make at this stage: explicitly naming what they would not build in V1. "I'd defer the multi-region replication and GraphQL API to V2. V1 needs working order placement and dispatch. Premature scaling optimizations are the primary cause of delayed launches."

This shows you can distinguish MVP from architecture-astronautics — a signal that correlates strongly with staff-level promotions.

What Most HLD Candidates Get Wrong (And Why It Costs Them)

After seeing hundreds of system design rounds across product company hiring, the failure patterns cluster into a few predictable mistakes:

Mistake 1: Treating requirements as a formality. The candidate asks the three clarifying questions because the framework says to, writes down the answers, and then designs a system that doesn't actually address them. The interviewer gave you a 100K QPS requirement and you drew a monolith with a single Postgres instance. The questions only matter if they visibly change your design.

Mistake 2: Box-and-arrow without justification. You draw a Kafka between the order service and the dispatch service. The interviewer asks: "Why not a direct REST call?" You say: "Kafka is better for async." That's not an answer. The answer is: "A direct REST call couples the order service's response time to the dispatch service's availability. If dispatch is slow or down, users can't place orders. Kafka decouples these timelines — users get an immediate order_created confirmation and dispatch happens asynchronously within our 2-second SLA."

Mistake 3: Memorizing architectures instead of deriving them. An interviewer at Swiggy will notice immediately if you're reciting a "design Uber" answer to a food delivery question. The problems look similar but the constraints differ: Swiggy's quick commerce (Instamart) has 10-minute SLAs requiring dark store proximity logic that a cab booking system doesn't need. Derived-from-requirements designs beat memorized templates every time.

Mistake 4: Skipping the state machine. For any system with multi-step workflows — orders, payments, delivery, bookings — the state machine is foundational. At Swiggy, the order state machine (placed → accepted → preparing → picked_up → delivered | cancelled) determines your event schema, your retry logic, and your consistency requirements at each transition. Candidates who don't draw the state machine usually can't answer "what happens if the restaurant marks the order ready but no driver has accepted?" because they never modeled the states.

Mistake 5: Silent thinking. The interviewer cannot grade what they can't observe. Ninety seconds of silent whiteboard staring is not thoughtful — it's unobservable. Think out loud: "I'm considering Postgres here because we need ACID for payment finalization, but I'm checking if our write volume justifies the connection pool overhead at 80K writes/sec..." That sentence shows reasoning, which is 60% of what's being graded.

Company-Specific Signals: What Razorpay, Swiggy, Flipkart, and Coupang Actually Listen For

Generic HLD frameworks produce generic answers. Product companies are interviewing for engineers who will work on their actual systems. Here's what the interviewers at each company are specifically listening for:

Razorpay and Stripe (payments infrastructure)

The signal interviewers listen for: "A timeout from the payment gateway represents an unknown, not a failure." This distinction is fundamental to payment system correctness. Most candidates retry on timeout — that risks double-charges. Correct behavior: query the gateway's status API with the original idempotency key, get a definitive state, then decide. Candidates who know this have clearly worked through payment system failure modes, not just designed the happy path.

Razorpay interviewers also listen for double-entry bookkeeping framing: the ledger is the source of truth; account balance is a derived value. Never store balance as a mutable field — derive it from debit/credit entries. This prevents an entire class of consistency bugs under concurrent updates.

Swiggy (food delivery + quick commerce)

The signal: Kafka semantics beyond "it's async." Interviewers want to hear: at-least-once delivery semantics, idempotent consumers, consumer group rebalancing behavior, and explicit acknowledgment that duplicate events are a normal operating condition, not an edge case. The candidate who says "I'd make the dispatch consumer idempotent by checking a Redis processed_events set before acting on any event" demonstrates production-level thinking.

Swiggy-specific addition: dark stores vs restaurants are architecturally different inventory systems. A dark store has fixed SKU inventory (can use simple reservation counters). A restaurant has real-time capacity (depends on kitchen load, not SKU count). If the question involves Instamart, your inventory model must account for this distinction.

Flipkart and Walmart (e-commerce at scale)

The signal: Big Billion Days / Black Friday concurrency. Flash sale architecture has one non-negotiable: inventory atomicity must happen in an operation that cannot split between a read and a write. Candidates who say "check availability, then decrement" are describing a race condition. The correct framing: atomic decrement via Redis Lua script or database-level UPDATE inventory SET qty = qty - 1 WHERE qty > 0 AND sku_id = $1 RETURNING qty — the WHERE qty > 0 guard plus the RETURNING clause makes the decrement atomic and gives you the result in one round trip.

Coupang (South Korea's largest e-commerce + logistics)

Coupang's rocket delivery promise (same-day, often within hours) means their logistics system has tighter SLAs than most e-commerce designs assume. If you're designing any logistics component for Coupang, you need to model warehouse proximity routing — which fulfilment center is closest to the delivery address — not just order routing. Candidates who treat fulfilment as a single warehouse get follow-up questions they can't answer.

The 30-Second Signal Check: Are You Ready to Execute the Framework?

Before your next interview, verify you can answer each of these in under 30 seconds each:

1. What's your first sentence after the interviewer gives you the problem statement?
2. Which 3 questions change the most architectures? (Not which 3 questions the framework says to ask.)
3. How do you calculate peak QPS from DAU, and what threshold makes you add a cache?
4. What's the justification for every component in your baseline template?
5. For your target company's domain (payments, food delivery, e-commerce), what is the hardest 1-in-100 failure mode that your design must handle?

If question 5 takes you more than 30 seconds, you haven't done enough domain-specific prep. The deep dive phase is won or lost on whether you've thought through the domain's specific failure modes before you walk in.

The system design practice problems on KnowEase are organized by these exact domains — payments, delivery, e-commerce, social feeds — with AI-graded rubrics across all four grading dimensions. Practicing with domain-specific feedback is the fastest way to close the gap between knowing the framework and executing it under pressure.

Quick Reference: The HLD Interview Framework

For scanning, for practice, for the night before:

| Phase | Minutes | Grade weight | Your goal | Time signal to interviewer | |---|---|---|---|---| | Requirements | 0–5 | 15% | 3 architecture-changing questions, state assumptions | "I'll spend 5 min on requirements, then estimation." | | Estimation | 5–8 | (part of HLD) | Derive conclusions, not just numbers | "Quick back-of-envelope — I'll use these to justify components." | | HLD + API | 8–22 | 25% | Every component justified from requirements | "Here's the high-level architecture — let me walk through the happy path." | | Deep dive | 22–38 | 35% | One component, three levels deep | "I want to go deep on [X] — it's the hardest part of this system." | | Trade-offs | 38–45 | 25% | Name costs, mitigations, and revisit conditions | "Can I take 2 minutes on the key trade-offs?" |

The clock matters less than the signal. Every time you announce a phase transition, you're demonstrating that you're running the interview, not surviving it. That meta-signal — structured communication under ambiguity — is what interviewers at Razorpay, Swiggy, Flipkart, Coupang, and Stripe are hiring for.

The engineer who manages 45 minutes well has already told you something about how they'll manage an on-call incident, a product launch, or a cross-team technical decision. That's why the HLD interview framework matters beyond interviews.