Low-Level Design (LLD) Learning Path

Low-Level Design (LLD) is the discipline of translating a problem statement into a set of well-structured classes, interfaces, and relationships that can be directly implemented as working code. Where High-Level Design focuses on system topology — services, databases, and networks — LLD focuses on the internal structure of a single service or component.

This module teaches LLD through real-world case studies. Every article starts from requirements, builds a class diagram, applies SOLID principles and design patterns, then walks through a complete Java implementation.

---

What Is Low-Level Design?

Low-Level Design answers the question: given a feature or system, how do we structure the code?

A well-executed LLD defines:

• Entities and their responsibilities — what each class owns and does
• Relationships — inheritance, composition, aggregation, and dependency
• Interfaces and abstractions — what contracts exist between components
• State transitions — how objects change over time in response to events
• Concurrency boundaries — where shared state requires synchronisation
• Extensibility points — where new behaviour can be added without breaking existing code

LLD sits between requirements and implementation. A good design makes the code self-documenting, easy to test, and cheap to change.

---

Why LLD Matters in Interviews

Most senior engineering interviews at product companies include at least one LLD round. Interviewers use it to evaluate whether a candidate can:

• Decompose a vague problem into concrete, well-named classes
• Apply SOLID principles instead of writing a monolithic class
• Choose the right design pattern for the right reason
• Handle concurrency without over-engineering
• Communicate a design clearly through a class diagram or whiteboard discussion

A common mistake is treating LLD as a purely academic exercise. The case studies in this module are all drawn from real systems that run at scale — parking management software, cinema booking platforms, hotel property management systems, banking ATM networks, and notification pipelines.

---

Prerequisites

Before starting this module you should be comfortable with:

• Core Java — classes, interfaces, abstract classes, enums, generics
• Object-Oriented Programming — encapsulation, inheritance, polymorphism
• Basic design patterns — at least a working knowledge of Strategy, Observer, Factory, and State
• SOLID principles at a conceptual level (Article 01 provides a full refresh)

---

Module Articles

#	Article	Core Concepts
01	SOLID Principles in LLD	SRP, OCP, LSP, ISP, DIP with Java examples and enterprise case studies
02	Parking Lot System	Entity modelling, multi-level floors, vehicle types, fee calculation, concurrency
03	Library Management System	Book catalog, member roles, borrowing lifecycle, reservations, fine engine
04	Movie Booking System	Show scheduling, seat lock, booking state machine, payment flow, race conditions
05	Hotel Reservation System	Room inventory, date-range availability, pricing strategy, cancellation and refund
06	ATM System	Card processing, PIN validation, transaction state machine, cash dispensing algorithm
07	Elevator System	SCAN scheduling, request queuing, direction control, multi-elevator coordination
08	Vending Machine	State pattern, inventory management, payment processing, change dispensing
09	Notification System	Multi-channel dispatch, template engine, retry logic, user preference routing
10	URL Shortener LLD	Encoding strategies, storage model, redirect flow, expiry, rate limiting
11	Cache Framework	Generic cache design, pluggable eviction policies (LRU, LFU, FIFO), TTL
12	Logging Framework	Log levels, appenders, formatters, chain-of-responsibility, extensible design
13	Rate Limiter LLD	Token Bucket, Sliding Window Counter, Fixed Window — class-level design
14	Task Scheduler	Job abstraction, priority queue, recurring tasks, execution thread management

---

Learning Flow

Work through the articles in order. The first article establishes the SOLID foundation. Articles 02–10 are classic interview case studies, each building on the design thinking from previous ones. Articles 11–14 focus on infrastructure components that appear inside many of the earlier systems.

flowchart TD
    A["01 SOLID Principles"] --> B["02 Parking Lot"]
    B --> C["03 Library Management"]
    C --> D["04 Movie Booking"]
    D --> E["05 Hotel Reservation"]
    E --> F["06 ATM System"]
    F --> G["07 Elevator System"]
    G --> H["08 Vending Machine"]
    H --> I["09 Notification System"]
    I --> J["10 URL Shortener LLD"]
    J --> K["11 Cache Framework"]
    K --> L["12 Logging Framework"]
    L --> M["13 Rate Limiter LLD"]
    M --> N["14 Task Scheduler"]

---

Design Patterns Covered

Each case study is deliberately chosen to showcase one or more design patterns in context rather than in isolation.

Pattern	Where It Appears
Strategy	Fee calculation (Parking Lot), payment methods (ATM, Vending Machine), eviction policy (Cache)
State	Booking lifecycle (Movie, Hotel), ATM transaction flow, Vending Machine operation
Observer	Notification routing, seat availability broadcast
Factory / Abstract Factory	Vehicle types (Parking Lot), room types (Hotel), log appenders (Logging Framework)
Singleton	Cache instance, scheduler engine, notification dispatcher
Command	Elevator request queue, Task Scheduler jobs
Template Method	Notification channel base class, rate limiter algorithm base
Chain of Responsibility	Log level filtering (Logging Framework)
Decorator	Rate limiter wrappers, notification enrichers

---

Key OOP Concepts Practiced

• Encapsulation — hiding internal state behind clean public APIs
• Inheritance vs Composition — choosing composition to avoid brittle hierarchies
• Polymorphism — treating concrete types through abstract interfaces
• Immutability — making value objects (Money, DateRange, Slot) immutable by default
• Concurrency — using locks, atomic operations, and optimistic locking to protect shared state

---

What You Will Be Able to Do

After completing this module you will be able to:

• Break down a plain-English problem into classes, responsibilities, and relationships within 5 minutes
• Draw a UML class diagram that communicates your design without ambiguity
• Apply SOLID principles so that each class has exactly one reason to change
• Identify which design pattern fits a given design problem and explain the trade-offs of alternatives
• Handle concurrency in booking, inventory, and counter-based systems
• Walk through any classic LLD interview round with a clear, structured approach

---

Common LLD Interview Mistakes to Avoid

• One god class — putting all logic in a single Manager or Service class instead of distributing responsibilities
• Skipping the state machine — failing to model the lifecycle of entities like bookings, transactions, or sessions
• Ignoring concurrency — not considering what happens when two users attempt the same action simultaneously
• Premature optimisation — jumping to caching or sharding before the basic design is clean
• No interfaces — coupling directly to concrete classes makes the design untestable and rigid

---

Next Module

Continue to SOLID Principles (Deep Dive) for an exhaustive treatment of each SOLID principle with Java and Spring Boot examples, including enterprise patterns in Banking, Insurance, Healthcare, and Retail domains.

---

Parent Learning Path

Return to the System Design Learning Path to review the full module order and continue with the complete learning path.