Learn Low-Level Design (LLD): A Practical Roadmap

Low-level design (LLD) is the step where you turn a feature into concrete classes, interfaces and methods: which objects exist, what each one is responsible for, how they talk to each other, and how the code behaves under failure and concurrent use. It's also called object-oriented design. LLD is what interviewers test in machine coding and LLD rounds, and it's what separates code that works once from code a team can extend.

This roadmap covers the six skills to learn, in order, and a problem to build at each step.

Updated 17 October 2026

What is low-level design?

High-level design (HLD) decides which components a system has: services, databases, queues, caches. Low-level design decides how each component is built inside.

	High-level design (HLD)	Low-level design (LLD)
Question	Which services and data stores, and how do they connect?	Which classes and interfaces, and how do they behave?
Output	Architecture diagram	Class model, interfaces, working code
Typical interview	"Design Twitter" on a whiteboard	"Build a parking lot / rate limiter" in code
Judged on	Scale, trade-offs, components	Responsibilities, extensibility, correctness

Why learn LLD?

Interviews. Many product companies run a dedicated LLD or machine coding round, and some include it at junior levels.
Day-to-day work. Most engineering time goes into changing existing code. Good LLD keeps those changes local instead of rippling through the codebase.
AI-assisted coding. When an assistant drafts code for you, judging whether the design is sound is the part that stays with you. See AI-enabled coding interviews.

The LLD roadmap: six skills in order

1. Object-oriented fundamentals

Encapsulation, abstraction, inheritance and polymorphism, and above all composition over inheritance. Practise modelling a small domain as objects that each own their data and behaviour, instead of one class that does everything.

Build: an employee management system. Small entities, clear ownership, fast lookups.

2. SOLID principles

Single responsibility: one reason to change per class.
Open/closed: add behaviour by adding code, not by editing what works.
Liskov substitution: subtypes must honour the contract of the type they replace.
Interface segregation: small, focused interfaces over one large one.
Dependency inversion: depend on interfaces, not concrete classes.

Use them as a review checklist, not a ritual. Every Cruscible problem starts from a contract interface, which is dependency inversion in practice.

3. Design patterns that actually come up

You don't need all 23 Gang of Four patterns. A handful cover most LLD problems:

Pattern	Use it when…	Where to practise it
Strategy	The algorithm must be swappable at runtime	Load balancer: four routing algorithms (round-robin, weighted, least-connections and more) behind one interface
State	Behaviour depends on a lifecycle with legal transitions	Circuit breaker (CLOSED → OPEN → HALF_OPEN), cab booking (ride state machine)
Observer	Several parts react to one event	Extension exercise: notify listeners when a deployment pipeline changes status
Decorator	You need to layer behaviour (logging, metrics) around a call	Extension exercise: wrap your retry engine calls with logging without changing them
Factory / Builder	Object creation has rules or many optional parts	Extension exercise: build validated bookings in railway reservation

Learn each one by recognising the problem it solves, not by memorising its UML.

4. Modelling: just enough UML

A quick class diagram (entities, key fields, relationships) and a sequence sketch of the main flow are enough to plan a 90-minute solution. Spend about 10 minutes here, then code.

5. Concurrency and correctness

This is where most "working" designs fail in practice. Two users book the last seat, a counter is incremented from many threads, a retry fires twice. Learn thread safety, atomic operations, locking and idempotency.

Build:

Parking lot: no two cars in one slot.
Railway reservation: no double-booked berths.
Sliding-window rate limiter: exact counts under concurrent requests.
Priority task queue: ordering, retries and a dead-letter queue.

6. Practise by building and getting graded

Reading designs doesn't build the skill; shipping them does. Work through problems from easy to expert, and treat each as a timed round:

Level	Problems	Main skill
Easy	Retry engine, employee management	Clean modelling, backoff and jitter
Medium	LRU cache, rate limiter, circuit breaker, task queue, parking lot	O(1) data structures, state machines, concurrency
Hard	Load balancer, URL shortener, cab booking, railway reservation	Pluggable algorithms, persistence, booking under contention
Expert	Deployment pipeline with rollback	Multi-step workflows with failure recovery

On Cruscible, each problem gives you a contract interface. Your code runs in an isolated container against real PostgreSQL, Redis or a key-value store, and is scored on functional correctness, performance and code quality. Java, Python, Go, Node.js and TypeScript are supported.

Browse all LLD problems →

How to approach any LLD problem

Clarify requirements. List the operations and the rules, and agree on what's out of scope.
Find the entities. Nouns become candidate classes; check each has one clear responsibility.
Define the interfaces first. Method signatures and return types, before any implementation.
Build the main flow end to end. The thinnest version that works.
Harden it. Edge cases, concurrency, failure handling, then the extension the interviewer asks for.

Common mistakes

Pattern-first design: forcing a pattern before the problem needs it.
God classes: one Manager class that knows everything.
Ignoring concurrency: code that passes a single-threaded demo and breaks under load.
No working code by the halfway mark: in a timed round, a running simple version beats an unfinished perfect one.

Frequently asked questions

How long does it take to learn low-level design?

With steady practice, most developers get comfortable with the fundamentals and common patterns in a few weeks. Fluency comes from building ten or more systems end to end.

Which language is best for LLD?

Any object-oriented language works. Java is the most common in LLD interviews and resources, but Python, Go and TypeScript are equally valid if you're faster in them.

Do I need to learn high-level design first?

No. LLD is often easier to start with, because you can practise it in code and check your work. HLD builds on the same thinking at a larger scale.

Is LLD only for senior engineers?

No. Many companies include LLD or machine coding rounds for early-career roles, because it shows how you structure code.