Low-Level Design Course
A free, hands-on low-level design (LLD) and machine-coding course: lessons on object-oriented design, UML class diagrams, SOLID, design patterns, concurrency and the machine-coding round. Every lesson has a class-diagram exercise that checks your design as you draw, and a quiz. Then design classic interview problems yourself and compare with a model answer.
How LLD interviews work
From a vague prompt to classes you can defend.
- What an LLD round really tests: Machine coding versus design discussion, the four things interviewers grade, and five steps for every LLD problem.
- From requirements to classes: Clarifying questions, nouns to classes and verbs to methods, where that rule fails, and one job per class, using SwiftKart coupons.
Object-oriented basics, the way interviewers check them
Encapsulation, abstraction, inheritance, composition and polymorphism, with code.
- Encapsulation and abstraction: Private state that guards an invariant, tell don't ask, and hiding how a job is done behind an interface, using SwiftKart's wallet.
- Inheritance, composition and polymorphism: Is-a versus has-a, the fragile base class, why to favour composition, and how polymorphism removes a switch on type.
Class diagrams you can draw in five minutes
Boxes, members, the six relationships and multiplicity.
- Reading and drawing a class box: The three parts of a class box, visibility symbols, static and abstract members, interfaces and enums, and your first use of the class designer.
- The six relationships and multiplicity: Association, dependency, aggregation, composition, inheritance and realisation, how each is drawn, and multiplicities such as 1, 0..1 and *.
SOLID, without the slogans
Five principles as five questions to ask of your design.
- Single responsibility, open/closed, Liskov: One reason to change per class, new coupons as new classes, and why a refund method that throws breaks substitution.
- Interface segregation and dependency inversion: Small interfaces shaped by their callers, business code that owns its abstractions, and constructor injection that makes checkout testable.
Creational patterns
Factory, builder and singleton: when to use them and when not to.
- Factory and abstract factory: Putting the choice of which notifier to build in one place, matching families of payment classes, and when a plain constructor is better.
- Builder and singleton: A builder for an order with many optional fields, the real costs of a singleton, and the simpler alternative of creating one instance and passing it in.
Structural patterns
Adapter, decorator, facade, composite and proxy.
- Adapter and facade: Wrapping two payment SDKs behind one interface you own, and giving checkout one simple method over six classes.
- Decorator, composite and proxy: Price add-ons as decorators instead of a subclass for every combination, category trees as composite, and a caching proxy.
Behavioural patterns I
Strategy and observer: swap behaviour, broadcast events.
- Strategy: Move each version of a rule (delivery fee, discount) into its own class behind one interface, pick one at runtime, and keep a switch when the cases never change.
- Observer: Let an order announce status changes to a list of listeners it does not know, and see how this in-process observer differs from publish-subscribe through a message broker.
Behavioural patterns II
State, command, chain of responsibility and template method.
- State and command: Model the order lifecycle as state classes that decide the next state, see how State differs from Strategy, and wrap cart actions as command objects for undo, retry and queueing.
- Chain of responsibility and template method: Split a long validation method into a chain of small handlers, and use template method to fix the order of payout steps while subclasses fill in the steps that differ.
Modelling behaviour: sequence and state diagrams
Who calls whom, and which states an object moves through.
- Sequence diagrams: Read and draw lifelines, calls, returns, activations and alt and loop boxes for SwiftKart checkout, and use the drawing to spot a class that does too much.
- State machines and state diagrams: Draw a payment's lifecycle as states, transitions and guards, reject moves the diagram does not allow, and turn the diagram into a transition table or State-pattern classes.
Concurrency in LLD
Thread safety, locks, and the double-booking problem.
- Thread safety basics: Race conditions on a counter and on stock, and the tools that fix them: synchronized, locks, atomics, immutable objects and concurrent maps.
- Double booking and producer-consumer: Booking a delivery slot safely with a pessimistic lock or an optimistic version check, and a blocking queue between the threads that take orders and the workers that send notifications.
The machine-coding round
Ninety minutes, a working program, and how you are graded.
- Planning the 90 minutes: A minute-by-minute plan for the machine-coding round: clarify, write models and interfaces first, keep data in in-memory repositories, finish with a main demo, and skip what is not graded.
- How you are graded, and extending live: What the machine-coding rubric checks, how to show your code works with small tests, how to add a new requirement live without breaking what runs, and the common ways candidates lose marks.