High-Level Design (Step 3 Deep Dive)

Advanced

Time Budget: 10–15 minutes — Sketch the core architecture. Cover the happy path first, then expand.

High-Level Design (HLD) is where you transform your scoped requirements and scale estimates into a working blueprint of the system. You are not solving every detail — you are proposing a coherent architecture that the interviewer can react to and guide.

Why It Matters

This is the phase where most candidates either shine or struggle. The interviewer wants to see:

Can you identify the right building blocks for the problem?
Do you know where each component lives in the architecture?
Can you articulate the data flow end-to-end?
Do you drive the conversation or wait to be led?

The HLD Flow

The 5 Core Building Blocks

Every system design uses some combination of these five layers. Know them cold.

Worked Example: URL Shortener

Carrying forward from Steps 1 & 2:

Functional: Shorten URL, Redirect, Custom Aliases, Expiration
Scale: ~1,200 writes/sec, ~116,000 reads/sec (100:1 read-heavy)
Storage: ~182 TB over 10 years → sharding needed
Cache: 10 GB working set → fits in Redis

Part 1 — Define the Core APIs

Before drawing anything, define what the system exposes to the outside world.

http

POST /api/v1/urls
  Request:  { long_url: string, custom_alias?: string, expiry_days?: number }
  Response: { short_url: string, expires_at: timestamp }

GET /{short_code}
  Response: HTTP 301 Redirect → long_url
            HTTP 404 if not found or expired

DELETE /api/v1/urls/{short_code}
  Response: HTTP 204 No Content

301 vs 302? — This is a classic interview trade-off:
301 (Permanent): Browser caches the redirect → fewer requests to our servers → lower load, but we lose click analytics.
302 (Temporary): Browser always hits our server → we can track analytics, but higher load.
Decision: Since analytics are out of scope for our baseline requirements, we will use 301 Permanent to minimize server load.

Part 2 — Design the Data Model

Key decision — SQL vs NoSQL?

Factor	Choice	Reason
Schema	Simple, fixed	Either works
Read pattern	Key-value lookup by `short_code`	✅ Favors NoSQL (Cassandra, DynamoDB)
Scale	182 TB, 116K reads/sec	✅ Favors NoSQL (sharding built-in)
Consistency	Eventual OK	✅ Favors NoSQL
Joins needed?	No	✅ Favors NoSQL

Decision: Use Cassandra or DynamoDB (NoSQL) with short_code as the partition key. This gives us distributed writes, fast key-value reads, and horizontal scaling out of the box.

Part 3 — Draw the High-Level Architecture

This is the core diagram you draw on the whiteboard.

Part 4 — Walk the Happy Path

Narrate the request flow end-to-end. This is exactly what you say to the interviewer:

Part 5 — The Short Code Generation Deep Dive

A common follow-up question: "How do you generate unique short codes?"

Best choice for interview: Option B (Base62 encoding of a distributed ID like Snowflake). It's collision-free, requires no extra DB lookup, and 7 Base62 characters gives us 62^7 = 3.5 trillion unique URLs — more than enough.

The HLD Output: At a Glance

Component	Technology Choice	Reason
DNS	Route 53 / Cloudflare	GeoDNS routing
CDN	CloudFront / Fastly	Cache hot redirects at the edge
Load Balancer	AWS ALB / Nginx	Distribute traffic, SSL termination
App Servers	Node.js / Go (stateless)	Horizontally scalable, auto-scaled
Cache	Redis (LRU, TTL-aware)	10 GB working set, ~95% hit rate
Database	Cassandra / DynamoDB	Native sharding, 182 TB scale
ID Generator	Snowflake / Base62	Collision-free short codes
Cleanup Worker	Cron job / Lambda	Purge expired URLs periodically

The Universal HLD Template

Apply this same structure to any system design question:

Step	What You Do	Time
APIs	Write 2-3 key endpoints on the board	2 min
Data Model	Sketch key tables/documents and relationships	2-3 min
Architecture Diagram	Draw boxes and arrows, label each component	5 min
Happy Path Walkthrough	Narrate a request end-to-end	2-3 min
Bottleneck Callout	Point to where the system will fail under load	1-2 min

Red Flags vs. Green Flags

🔴 Red Flag	🟢 Green Flag
Draw the architecture without defining APIs first	Always start with APIs — they define the system's contract
Use a single giant server	Show horizontal scaling from the start
Never mention the database choice	Explicitly state SQL vs NoSQL and why
Draw components but don't explain data flow	Walk through the happy path out loud
Jump to optimization before the basics work	Get the happy path working, then optimize
Generic diagram that could apply to any system	Tailor every component to your specific requirements

Next Steps

With the high-level design in place, move to Step 4: Deep Dive & Detailed Design → where you zoom into individual components to address bottlenecks, edge cases, and trade-offs.

IMPORTANT

Always get buy-in before moving on. After drawing your architecture, ask: "Does this high-level design look reasonable? Are there areas you'd like me to go deeper on?" This is your chance to show collaboration and redirect your energy to what the interviewer cares most about.

TIP

If you run out of time, a complete HLD with clear trade-off reasoning is more impressive than a partial deep-dive. Breadth first, then depth.

High-Level Design (Step 3 Deep Dive) ​

Why It Matters ​

The HLD Flow ​

The 5 Core Building Blocks ​

Worked Example: URL Shortener ​

Part 1 — Define the Core APIs ​

Part 2 — Design the Data Model ​

Part 3 — Draw the High-Level Architecture ​

Part 4 — Walk the Happy Path ​

Part 5 — The Short Code Generation Deep Dive ​

The HLD Output: At a Glance ​

The Universal HLD Template ​

Red Flags vs. Green Flags ​

Next Steps ​