From SOLID to System Design: a practical roadmap for LLD and HLD interviews

"Learn system design" is advice that sounds useful and gives you nothing to do on Monday morning. The topic is huge, YouTube is full of 45-minute "design Netflix" videos, and it's easy to watch twenty of them and still freeze when an interviewer says "design a parking lot".

The fix is to learn it in the right order. Design skill stacks: object design sits on principles, and architecture sits on object design and fundamentals. Here's the roadmap I'd follow, and the one DevInterviewMaster's learning path is built around: SOLID → Design Patterns → Low-Level Design → High-Level Design.

Stage 1: SOLID principles (1–2 weeks)

SOLID isn't trivia to recite. It's a vocabulary for talking about the cost of change.

• Single Responsibility: a class should have one reason to change. If your OrderService also formats emails and talks to the payment gateway, every change risks everything.
• Open/Closed: add behaviour by adding code, not by editing a growing if/else chain.
• Liskov Substitution: a subclass must honour the parent's contract. The classic square/rectangle problem is the interview favourite.
• Interface Segregation: many small interfaces beat one fat one that forces empty implementations.
• Dependency Inversion: depend on abstractions, so you can swap a real payment gateway for a fake one in tests.

Exit test: take a 200-line class you wrote and explain which principle it breaks and what that will cost you later.

Stage 2: Design patterns (2–3 weeks)

Don't memorise a catalogue. For each pattern, learn the problem it solves and its trade-off. Prioritise the ones that come up again and again in LLD rounds:

• Strategy: swap algorithms at runtime (pricing rules, payment methods).
• Factory / Abstract Factory: centralise object creation.
• Observer: notify subscribers of events (notifications, order status).
• State: behaviour that changes with state. Vending machines, elevators and order lifecycles are exactly this.
• Decorator: add behaviour without subclass explosion.
• Singleton: know it, and know why it's often a smell (global state, testing pain).
• Builder, Adapter, Command: frequent supporting cast.

Exit test: given "design a vending machine", you can say which pattern you'd use and why, in two sentences.

Stage 3: Low-Level Design (3–4 weeks)

LLD rounds ask you to turn requirements into classes, interfaces and working code. A repeatable approach:

1. Clarify use cases and invariants. "Two cars can never be assigned the same spot" is an invariant, and your design must protect it.
2. Identify entities and responsibilities. Which object owns each rule?
3. Define interfaces and relationships. Composition over inheritance by default.
4. Implement one core flow end-to-end. Interviewers want running logic, not just a class diagram.
5. Test the design against change. "Now add electric-vehicle charging spots": how many classes do you touch?
6. Discuss concurrency if relevant. Two requests reserving the same spot at once is a race condition (see stage 4 thinking).

Classic practice problems: parking lot, elevator system, vending machine, library management, splitwise, rate limiter (LLD version), LRU cache, BookMyShow-style seat booking.

Stage 4: High-Level Design (4–6+ weeks)

Now zoom out to services, data flow and failure. Use the same six steps for every question:

1. Clarify requirements: users, core actions, scale, and what's explicitly out of scope.
2. Estimate scale: QPS, storage, read/write ratio, latency targets, with units.
3. Design APIs and the data model before drawing boxes.
4. Draw the core flow: trace one request end-to-end.
5. Handle scale and failure: caching, queues, partitioning, replication, retries. Add each only when you can say why it's needed.
6. Defend trade-offs: consistency vs availability, cost vs complexity, and what would change your mind.

Fundamentals to cover: load balancing, caching strategies and invalidation, SQL vs NoSQL, indexing, replication and partitioning, consistent hashing, message queues and event-driven design, rate limiting, CDNs, idempotency, and observability.

Start with these five problems, because together they cover most building blocks: URL shortener, rate limiter, notification service, chat system, file storage.

What changes by level

• SDE-1: fundamentals, small object designs, clean code. LLD matters more than HLD.
• SDE-2: both rounds; expect deeper trade-offs and failure handling.
• Senior: HLD dominates, with emphasis on reliability, operability and cost. Real production incidents become great material here.

A realistic 12-week plan

Throughout, practise explaining out loud. System design interviews are conversations. Record yourself, or explain to a friend (or a tutor) and see where you hand-wave.

DevInterviewMaster follows exactly this path, SOLID → design patterns → LLD (70 topics) → HLD (248 topics), with an AI tutor for HLD and LLD that you can talk to in English, Hindi or Hinglish. The overview is free at devinterviewmaster.com/system-design.