Interview Prep
High-Level Design
High-level design is the art of capturing a system's essence in a single diagram. Learn to identify the right components, show data flow, and communicate architecture clearly.
- Abstraction β Focus on what, not how
- Clarity β Make the diagram readable in 30 seconds
- Completeness β Cover all major components and their interactions
A good high-level design is a conversation starter, not a final specification.
The High-Level Design Process
High-level design identifies the major components of a system and their interactions, without diving into implementation details.
DfHigh-Level Design
A high-level design is an architectural blueprint that identifies the system's major components, their responsibilities, and how they interact. It focuses on the "what" rather than the "how"βdefining component boundaries and data flow without specifying internal implementation details. A good high-level design is readable in 2-3 minutes and serves as a roadmap for detailed design.
The Three-Layer Architecture
Most systems follow a three-layer pattern:
The Component Identification Checklist
Before drawing your diagram, identify which of these components your system needs:
| Component | When to Include |
|---|---|
| Load Balancer | Multiple server instances, high availability |
| API Gateway | Multiple client types, need for rate limiting/auth |
| CDN | Static content, global audience, low latency |
| Cache | High read throughput, expensive computations |
| Message Queue | Async processing, decoupling, buffer for spikes |
| Search Engine | Full-text search, complex queries |
| Object Storage | Files, images, videos, large blobs |
| Database | Persistent data storage (choose type based on access pattern) |
Not every system needs every component. A simple CRUD application might just need a web server and database. The key is to include components that address your specific requirements and constraints.
Data Flow Patterns
Understanding common data flow patterns helps you design the right architecture:
Pattern 1: Synchronous Request-Response
DfSynchronous Pattern
In a synchronous pattern, the client sends a request and waits for the response. The entire chain of calls must complete before the user sees a result. This is simple but creates tight coupling and can lead to cascading failures.
Client β API β Service A β Service B β Database β Response
Pattern 2: Asynchronous Event-Driven
DfAsynchronous Pattern
In an asynchronous pattern, the client sends a request and receives an immediate acknowledgment. Processing happens in the background, and the client is notified when complete. This improves responsiveness and resilience but adds complexity.
Client β API β Queue β Service A β Event β Service B
Pattern 3: CQRS (Command Query Responsibility Segregation)
DfCQRS
CQRS separates read and write models. Commands (writes) go to one model, queries (reads) go to another. This allows independent optimization of read and write paths, at the cost of eventual consistency between models.
Write Path: Client β Command API β Write Model β Database β Event
Read Path: Client β Query API β Read Model (denormalized) β Cache
Designing for Key Requirements
Map requirements to architectural decisions:
Architecture Selection
Here,
- =The chosen architecture pattern
- =Requirement i
- =Weight/importance of requirement i
- =How well architecture A satisfies requirement i
| Requirement | Architectural Decision |
|---|---|
| High read throughput | Read replicas, CDN, caching |
| High write throughput | Sharding, write-ahead logs, event sourcing |
| Low latency | Cache, CDN, connection pooling, keep-alive |
| Strong consistency | Synchronous replication, distributed transactions |
| Eventual consistency | Async replication, conflict resolution |
| Global availability | Multi-region, active-active, edge computing |
| Complex search | Elasticsearch, inverted indices |
| Real-time updates | WebSockets, server-sent events, pub/sub |
When presenting your high-level design, start with the simplest architecture that meets the requirements, then explain what you would add and why. This shows you can design for current needs while thinking ahead.
The Drawing Template
Use this template for your interview diagrams:
Essential Elements
- Clients (top) β Web, mobile, 3rd party
- Edge Layer β CDN, load balancer, API gateway
- Service Layer β Core services, microservices
- Data Layer β Databases, caches, queues
- Arrows β Show data flow direction
- Labels β Name each component
Labeling Convention
- Solid arrows: Synchronous calls
- Dashed arrows: Asynchronous calls
- Dotted arrows: Data replication
- Bold components: Critical path
Common Mistakes in High-Level Design
- Too much detail β Don't show database schemas or API endpoints
- Too little detail β Missing components like load balancers or caches
- No data flow β Arrows without direction or purpose
- Overcomplicating β Including components you can't justify
- Ignoring scale β Not showing replication or sharding
The high-level design should be understandable by a non-technical stakeholder. If your diagram requires a legend or explanation beyond component names, it's too complex. Simplify until it's immediately clear.
Practice Exercises
-
Component Identification: For a system like Instagram, list all the components you would include in your high-level design. Justify each component's inclusion based on requirements.
-
Data Flow Design: Sketch the data flow for a user uploading a photo to Instagram. Include all components the request touches from upload to appearing in another user's feed.
-
Pattern Selection: For each scenario, choose the most appropriate data flow pattern (synchronous, asynchronous, CQRS) and justify your choice:
- User placing an order on an e-commerce site
- User viewing their social media feed
- System processing a payment
-
Requirement Mapping: Given these requirements, identify the architectural decisions:
- 10M daily active users, 99.9% uptime, <200ms P95 latency
- Strong consistency for financial transactions
- Global availability across 5 continents
Key Takeaways:
- High-level design focuses on components and their interactions, not implementation details
- Follow the three-layer pattern: Client, Application, Data
- Choose data flow patterns based on consistency and latency requirements
- Map requirements directly to architectural decisions
- Keep diagrams simple enough to be understood in 30 seconds
What to Learn Next
-> Deep Dive Design Methods for diving deep into critical system components.
-> System Design Interview Framework The five-phase framework for structured system design interviews.
-> Requirements Gathering Deep dive into eliciting and categorizing system requirements.
-> Estimation Techniques Master back-of-the-envelope calculations for capacity planning.
-> Load Balancing Distribution algorithms and L4 vs L7 load balancing.
-> Message Queues Async processing, event-driven architecture, and pub/sub patterns.