What is High Level Design in system design?
High Level Design (HLD) is a system architecture blueprint that outlines the overall system structure, major components, their interactions, and the flow of data without diving into implementation details.
High Level Design (HLD) is the first major phase in system design that creates an architectural blueprint of the entire system. It focuses on the big picture: defining the system's modules, their responsibilities, how they communicate, and the data flow between them. HLD answers questions like "What are the major components?" and "How do they interact?" without specifying implementation details like specific programming languages, database schemas, or API endpoints. This phase is critical for establishing a shared understanding among stakeholders, identifying potential bottlenecks early, and providing a roadmap for detailed design and implementation.
A typical HLD includes architectural diagrams showing the placement of components such as load balancers, application servers, databases, caches, message queues, and CDNs. It defines component responsibilities, communication protocols (HTTP, WebSocket, gRPC), data flow patterns, and external integrations. The HLD also addresses non-functional requirements like scalability, availability, latency, and security at a conceptual level. Key deliverables include system architecture diagrams, component interaction diagrams, technology stack decisions, and deployment strategies.
- 1
System Architecture Diagram: Visual representation showing all major components and their connections, including clients, load balancers, application servers, databases, caches, and external services.
- 2
Component Decomposition: Breaking the system into logical modules (e.g., user service, payment service, notification service) with clearly defined responsibilities and boundaries.
- 3
Data Flow: Documentation of how data moves through the system, including request/response paths, event propagation, and data synchronization between components.
- 4
Technology Stack: High-level decisions about infrastructure (cloud provider, containerization), databases (SQL vs NoSQL), caching, and message brokers.
- 5
Non-Functional Requirements: Scalability strategies (horizontal scaling, sharding), availability targets (SLA, failover), latency budgets, and security considerations.
- 6
External Integrations: How the system interacts with third-party services, APIs, or legacy systems, including authentication methods and data exchange formats.
- 1
HLD (High Level Design): Focuses on system architecture, component interactions, and technology choices. Outputs include architecture diagrams and module responsibilities.
- 2
LLD (Low Level Design): Dives into implementation details for each component. Includes class diagrams, database schemas, API specifications, and algorithm design.
- 3
Audience: HLD is for architects, project managers, and stakeholders. LLD is for developers implementing specific modules.
- 4
Abstraction Level: HLD works at the 10,000-foot view. LLD works at the 100-foot view with concrete implementations.
Creating an effective HLD requires balancing detail with clarity. It should be comprehensive enough to guide development but not so prescriptive that it restricts implementation creativity. The iterative nature of system design means HLD evolves with new requirements and constraints. Trade-offs are documented explicitly—for example, choosing eventual consistency over strong consistency for performance gains, or selecting a message queue over synchronous calls for resilience. These decisions, along with their rationales, become part of the HLD documentation.
Scenario Questions
0-2 years experience
- 1We need a simple one‑to‑one chat feature for a mobile app. How would you sketch the high‑level design and what main pieces would you include?
- 2If you add a file‑upload capability to an existing todo list service, what new high‑level components would you introduce and why?
2-5 years experience
- 1Our video platform now wants to support live streaming. Walk me through the high‑level design changes you’d propose and the trade‑offs involved.
- 2The checkout flow in our e‑commerce site is suddenly slow. How would you use a high‑level design view to pinpoint where the bottleneck might be?
5-8 years experience
- 1Design a high‑level architecture for a global ride‑hailing service that must handle millions of requests per second. Discuss component choices, data flow, and scalability trade‑offs.
- 2Our microservice ecosystem has grown to dozens of services and deployments are getting risky. How would you restructure the high‑level design to improve fault isolation and deployment velocity?
8+ years experience
- 1We have a legacy monolith that needs to be broken into services over the next few years. Outline a high‑level migration strategy and the design principles you’d enforce during the transition.
- 2The company wants a unified data platform that serves multiple product lines. How would you define the high‑level design to ensure cross‑team ownership, data consistency, and long‑term scalability?
Follow-up Questions
- What criteria do you use to decide the boundaries between those high‑level components?
- How would you verify that your high‑level design satisfies latency and availability requirements?
- Can you give an example of a trade‑off you might make when choosing a technology for a core component?