LLD vs HLD

In software architecture, systems are designed at two distinct levels of abstraction: High-Level Design (HLD), which focuses on the macro-architecture and infrastructure, and Low-Level Design (LLD), which focuses on micro-structures and class relationships. This lesson contrasts their scopes and boundaries.

1. Learning Objectives

• Differentiate the boundaries and artifacts of HLD vs LLD.
• Map macro architectural choices down to object-oriented code designs.
• Identify which stakeholders reference HLD and LLD documents.

2. Problem Statement

When building large-scale software systems:

• If you only do HLD: Developers are left with vague architecture blocks (e.g. "User Service") and have to guess class hierarchies, leading to inconsistent codebase structures and bad design habits.
• If you only do LLD: You focus on writing classes but miss how services scale, choose the wrong databases, or suffer server crashes because you ignored system distribution.

3. Real-world Analogy

4. Theory

High-Level and Low-Level Design represent two complementary phases in the software design lifecycle:

Feature	High-Level Design (HLD)	Low-Level Design (LLD)
Focus Query	What components make up the system?	How do internal classes implement components?
Key Output	System architecture, DB choices, cloud topology	Class diagrams, method signatures, design patterns
Stakeholders	Product managers, Solution architects, Clients	Software developers, Tech leads, QA engineers

5. Visual Diagram

This diagram displays how HLD decisions flow down to concrete LLD class architectures:

6. Syntax Explanation

To show this division, let's look at how an HLD decision ("Implement a User API with caching") is written inside an LLD class structure.

• We create a CacheService interface to outline the get/put methods.
• We implement a MockRedisCache to wrap the mock cache connection.

7. Step-by-Step Implementation

Let's code this. We will:

• Step 1: Declare a CacheService interface (LLD abstraction of the HLD decision "Use Redis Cache").
• Step 2: Implement the interface with a concrete RedisCache class.
• Step 3: Build the UserService class that depends on the cache interface.

8. Complete Code

9. Code Walkthrough

In the code, the choice of a specific server ("Redis Cache") is an HLD architectural choice. However, how we abstract that connection in an interface (CacheService) and how the business logic handles cache misses and cache writes (UserService) is purely an LLD decision.

10. Execution Flow

• Instantiate concrete RedisCache.
• Initialize UserService injecting the cache handler.
• Invoke getUserProfile(userId).
• The service queries the cache. On miss, it generates the model value and calls .put(key, value) to cache it.

11. Internal Working

Under the hood, the caching interface acts as a virtual boundary. Method execution resolves via dynamic lookup table redirects, keeping the controller isolated from direct connection pools.

12. Complexity Analysis

• Time Complexity: $O(1)$ to query and write cache configurations.
• Space Complexity: $O(N)$ where $N$ represents count of cache items in storage maps.

13. Best Practices

• Verify design alignment: Confirm that all LLD class interfaces match API contracts established in HLD.
• Shield technologies: Wrap concrete systems (e.g. databases, message queues) in interfaces so code can compile in tests without connection servers.

14. Common Mistakes

• Specifying code class methods inside HLD documents (this clutters macro architectures).
• Making HLD decisions inside LLD (e.g. swapping the database schema design completely without updating solution architects).

15. Interview Questions

16. Practice Exercises

• Easy: Add a new MemoryCache implementation and verify it behaves correctly.
• Medium: Add an expiration duration check parameter to the .put(key, value) cache interface method.
• Hard: Create a database write-through caching strategy wrapper using the classes designed above.

17. Challenge Problem

Design the low-level classes, methods, and relationships to implement the HLD selection: "Use an API Gateway with rate limiting."

18. Summary

• HLD is macro-focused, defining boundaries, routing protocols, and server infrastructure.
• LLD is micro-focused, defining class hierarchies, attributes, relationships, and code contracts.
• Both phases are complementary and required to build scalable systems.

19. Cheat Sheet

Category	HLD Boundary	LLD Boundary
API	URL endpoints, status codes, JSON payload schemas	Controller class, interceptors, parameter validation methods
Database	Database server selection, sharding strategies, indexing rules	DAO classes, ORM mapping models, Repository interface
Scaling	Load balancers, replication nodes	Thread pools, concurrency locks, connection pools

20. Quiz

21. Next Lesson Preview

In the next lesson, we will explore Design Thinking and analyze how to systematically approach requirement breakdowns before writing any design structures or code configurations!