Drawing the high-level design
In one line
Draw the simplest set of boxes that meets the requirements, organised in layers, then prove it works by walking one write and one read through it.
What it is
The high-level design (HLD) is the whiteboard diagram of the main components and how requests and data move between them: clients, edge (CDN, load balancer, API gateway), services, asynchronous parts (queues, stream processors, workers), data stores (databases, caches, object storage) and external systems (payment gateways, SMS providers, LLM APIs).
A good HLD is small. Eight to twelve boxes is typical. Each box has a reason to exist that you can link to a requirement or an estimate. Arrows show direction and whether a call is synchronous (the caller waits) or asynchronous (through a queue or event).
The HLD is the map for the rest of the interview. Deep dives zoom into one box or one arrow, so the diagram must be clear enough that you and the interviewer can point at it.
Why interviewers ask
The HLD is where the interviewer checks that you can produce a complete, working system before optimising. Many candidates either draw a cloud of fashionable boxes with no clear flow, or never reach a full design because they went deep too early. A clean diagram with a traced request path is the minimum bar at every level.
How it works
- 1Start with the version that works for a small scale: client, one API service, one database. Say it out loud, then grow it only where your estimates demand.
- 2Lay out in layers from top to bottom: clients, edge, services, async, data, external. This keeps arrows flowing in one direction and makes the diagram easy to read.
- 3Split services by responsibility and by scaling needs, not by habit: a read-heavy feed service and a write-heavy ingestion service scale differently. Two to five services is enough for most interviews.
- 4Put a queue or log (Kafka, SQS, RabbitMQ) on any path where work is slow, can be retried, has spiky load, or fans out to several consumers: notifications, transcoding, search indexing, analytics.
- 5Add caches and CDNs in front of hot reads, and object storage for files with direct upload via pre-signed URLs, so large bytes do not pass through your services.
- 6Mark the source of truth for each kind of data, and the derived copies (cache, search index, analytics).
- 7Trace the write path step by step through the boxes, naming the data at each hop, then trace the read path. Gaps appear immediately.
- 8Point out the parts you plan to deep-dive and the obvious risks (single points of failure, hot keys) so the interviewer knows you see them.
Worked example · HLD for a short-video app like Moj or Reels
- Clients: Android, iOS. Edge: CDN for video segments, API gateway for auth and rate limits, load balancer.
- Services: Upload service (issues pre-signed URLs, creates video records), Feed service (returns a ranked list of video IDs), Engagement service (likes, views, comments).
- Async: upload-complete events on Kafka feed a transcoding worker pool (produces 240p to 1080p HLS renditions) and a moderation worker; engagement events go to Kafka for counters and ranking features.
- Data: Postgres or MySQL for video metadata and users, Redis for precomputed feed candidates and counters, object storage (S3 or GCS) for originals and transcoded segments.
- External: a recommendation model service and a push notification provider.
- Write path: app asks Upload service for a URL, uploads 30 MB straight to object storage, storage event goes to Kafka, transcoder writes renditions, marks the video ready, moderation approves it, and it becomes eligible for feeds.
- Read path: app calls GET /feed, Feed service reads candidate IDs from Redis, fetches metadata (cached), returns 10 items with CDN URLs; the player streams segments from the CDN, not from our servers.
Picture it
It is like a city metro map. It does not show every street, only the stations and lines that matter, laid out so anyone can trace a journey from A to B. The detailed station plans come later.
Key patterns
Separate read path and write path
When: Reads and writes have very different volume or latency needs
How: Writes go to the source of truth and emit events; reads come from caches or precomputed views built from those events.
Bytes bypass services
When: Uploads or downloads of images, video, files
How: Use pre-signed URLs for upload to object storage and a CDN for download, so services handle only small metadata requests.
Async for slow, spiky or fan-out work
When: Work the user does not need to wait for
How: Put it behind a durable queue or log with idempotent consumers and retries, and keep the user-facing request short.
Real-world use
Netflix: control plane vs data plane
Netflix runs its control plane (browsing, recommendations, playback authorisation) on AWS, while video bytes come from its Open Connect CDN appliances inside ISP networks. Separating the heavy byte path from the API path is a common HLD move.
Swiggy and Zomato order flow
Food delivery platforms split ordering, restaurant, delivery-partner assignment and location tracking into separate services, because location tracking has far higher write rates than order placement.
The C4 model
Simon Brown's C4 model (context, containers, components, code) is a widely used way to draw architecture at the right zoom level. An interview HLD is roughly the 'containers' level.
In a project
You join a team whose monolith sends emails, generates invoices and calls a payment gateway inside the checkout request. Checkout p99 is 6 seconds and fails whenever the email provider is slow.
- Draw the current HLD and trace the checkout request: it waits on four external calls in sequence.
- Keep only what the user must wait for in the synchronous path: create order, call payment, return status.
- Write an OrderPlaced event to an outbox table in the same transaction as the order, and publish it to Kafka.
- Move email, invoice PDF generation and analytics into consumers of OrderPlaced, each with its own retries.
- Redraw the HLD with the async layer and show the new request path to the team.
Impact: Checkout p99 falls to under 1.5 seconds, email provider outages no longer fail orders, and each side task can be scaled and retried on its own.
Trade-offs
Use it when
- After requirements, estimates, API and data model are agreed
- When the interviewer asks 'show me the overall system'
- Before any deep dive, to make sure the full flow works
Avoid it when
- Adding microservices, Kafka or Kubernetes when the scale fits a simple monolith plus a database
- Drawing every internal module; keep internal details for the deep dive
- Spending more than about 10 minutes on the diagram before going deep
Common mistakes
- Drawing boxes with no arrows or with arrows that go everywhere.
- Adding components because they are popular, without linking them to a requirement.
- Sending large files through API servers instead of object storage and a CDN.
- Calling slow third parties (email, SMS, PDF generation) inside the user request.
- Never tracing a request, so missing pieces stay hidden.
- Not marking the source of truth, so cache or search index consistency is unclear.
- Forgetting the load balancer or multiple instances, leaving single points of failure.
Interview questions
Quick revision
- Start with client, service, database; grow only where numbers demand.
- Layers top to bottom: clients, edge, services, async, data, external.
- 8 to 12 boxes; each one tied to a requirement.
- Arrows: direction plus sync or async.
- Queue for slow, retryable, spiky or fan-out work.
- Files: pre-signed upload to object storage, CDN for reads.
- Mark the source of truth and the derived copies.
- Trace one write and one read end to end.
- Name the risky parts you will deep-dive.
Check yourself
1. Where should a 50 MB video upload go in a well-designed HLD?
2. Which work belongs on an asynchronous path behind a queue?
3. What is the best way to check an HLD for missing pieces?
4. Your estimates show 200 requests per second and 20 GB of data. Which HLD fits best?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.