Low-Level Design

• Classes & ObjectscoreLessonBlueprints vs instances; fields, methods, constructors.
• Object lifecycleLessonConstruction, initialization, and cleanup / destructors.
• EncapsulationcoreLessonHide state behind behavior; getters/setters done right.
• AbstractioncoreLessonExpose intent, hide the implementation details.
• InheritanceLessonReuse and specialization through an "is-a" relationship.
• PolymorphismcoreLessonOne interface, many forms; overriding vs overloading.
• Static vs instance membersLessonClass-level state and behavior vs per-object.
• Access modifiersLessonpublic, private, protected, package — controlling visibility.
• Abstract classes vs InterfacesinterviewLessonShared base vs pure contract — when to use which.
• Composition vs InheritancecoreLessonFavor composition; "has-a" beats "is-a" more often than you think.
• Association, Aggregation, CompositionLessonObject relationships and who owns whose lifecycle.
• Coupling & CohesioncoreLessonThe two metrics that quietly decide design quality.
• equals(), hashCode() & identityLessonContracts that bite the moment objects enter collections.
• Immutability & value objectsLessonObjects that can't change are simpler and thread-safe by default.
• Generics / TemplatesLessonType-safe reuse without casting everywhere.
• Enums & constantsLessonModeling a fixed, finite set of options cleanly.

• Requirement gathering & clarifying questionsinterviewPin down scope and assumptions before designing anything.
• Identifying entities, attributes & behaviorscoreNouns become classes, verbs become methods.
• Responsibility assignment (GRASP)Information Expert, Creator, Controller, and friends.
• CRC cardsClass–Responsibility–Collaborator brainstorming on paper.
• Domain modelingEntities, value objects, and services that mirror the real domain.
• Designing the API firstcoreAgree on contracts and method signatures before implementing.

• Class diagramscoreStructure, relationships, multiplicity — the LLD workhorse.
• Object diagramsA concrete snapshot of instances at one moment.
• Sequence diagramsinterviewHow objects collaborate over time, message by message.
• Use case diagramsActors and the goals they pursue with the system.
• Activity diagramsWorkflows, branches, and parallel paths.
• State diagramsAn object's lifecycle and its valid transitions.
• Component & deployment diagramsZooming out to modules and where they run.
• Relationship notationAssociation, dependency, generalization, realization.

• Single Responsibility (SRP)coreA class should have one, and only one, reason to change.
• Open/Closed (OCP)coreOpen for extension, closed for modification.
• Liskov Substitution (LSP)interviewSubtypes must be usable anywhere their base type is.
• Interface Segregation (ISP)Many small, focused interfaces beat one fat one.
• Dependency Inversion (DIP)coreDepend on abstractions, never on concretions.

• DRY, KISS, YAGNIcoreDon't repeat yourself, keep it simple, don't build what you don't need.
• Law of DemeterTalk to your friends, not to strangers' internals.
• Separation of ConcernsEach module owns one well-defined job.
• Program to interfacescoreCode against contracts, not concrete implementations.
• Dependency Injection & IoCinterviewHand dependencies in instead of creating them inside.
• Tell, Don't AskPush behavior to the data instead of pulling data out.
• Command–Query SeparationA method either does something or answers something — not both.

Creational

• SingletonOne shared instance, globally reachable.
• Factory MethodDefer which class to instantiate to subclasses.
• Abstract FactoryCreate families of related objects.
• BuilderAssemble complex objects step by step.
• PrototypeClone an existing object instead of building anew.
• Object PoolReuse expensive objects instead of recreating them.

Structural

• AdapterMake incompatible interfaces work together.
• BridgeSplit abstraction from implementation so both can vary.
• CompositeTreat trees of objects like a single object.
• DecoratorAdd behavior by wrapping, not subclassing.
• FacadeOne simple front door to a complex subsystem.
• FlyweightShare common state across many objects to save memory.
• ProxyA stand-in that controls access to the real object.

Behavioral

• Chain of ResponsibilityPass a request along a chain of handlers.
• CommandWrap an action as an object you can queue or undo.
• IteratorTraverse a collection without exposing its internals.
• MediatorCentralize tangled object-to-object communication.
• MementoCapture and restore an object's state.
• ObserverinterviewNotify dependents automatically when state changes.
• StateChange behavior when the internal state changes.
• StrategyinterviewSwap interchangeable algorithms at runtime.
• Template MethodFix the skeleton, let subclasses fill the steps.
• VisitorAdd operations to a hierarchy without touching it.
• Null ObjectA do-nothing default that removes null checks.

Architectural

• MVC / MVP / MVVMSeparating data, presentation, and control.
• RepositoryAbstract data access behind a collection-like API.
• Pub/Sub & Event-drivenDecouple producers from consumers via events.

• Threads & lifecycleCreating, starting, and coordinating threads.
• Locks, Mutex, SemaphorecoreThe core tools for guarding shared state.
• Thread-safe SingletoninterviewDouble-checked locking and the holder idiom.
• Producer–ConsumerinterviewBounded buffers and blocking queues.
• Read-Write locksLet many readers in, one writer at a time.
• Deadlock, race conditions, starvationcoreThe three classic ways concurrency goes wrong.
• Atomic operations & CASLock-free updates with compare-and-swap.
• Thread pools & ExecutorsReuse a fixed set of workers instead of spawning threads.
• Futures, Promises & asyncComposing results that aren't ready yet.
• Immutable objects for safetyShare freely when nothing can change underneath.

The approach

• A repeatable 5-step frameworkinterviewClarify → entities → APIs → class diagram → code → test.

Beginner

• Parking LotThe canonical warm-up problem.
• Vending MachineState machine over products and coins.
• ATMTransactions, balances, and a state flow.
• Tic-Tac-ToeBoard, players, and win detection.
• Snake & LadderDice, board, and turn management.
• Coffee MachineRecipes, ingredients, and inventory.

Intermediate

• Elevator / Lift systemScheduling and request dispatch.
• Library ManagementCatalog, members, and loans.
• Logging frameworkLevels, appenders, and formatting.
• Rate LimiterToken bucket and sliding windows.
• Notification systemChannels, templates, and routing.
• Cache (LRU / LFU)Eviction policy behind a clean API.
• SplitwiseExpenses, balances, and settlements.
• Meeting room schedulerIntervals, conflicts, and booking.
• In-memory key-value storeGet/set with TTL and eviction.

Advanced

• BookMyShowSeats, shows, and concurrent booking.
• Food delivery (Swiggy / Zomato)Restaurants, carts, and dispatch.
• Ride sharing (Uber / Ola)Matching, pricing, and trips.
• Hotel bookingInventory, availability, and rates.
• ChessPieces, moves, and rule validation.
• Stock exchange / Order matchingOrder book and a matching engine.
• Online IDE / Code editorFiles, sessions, and execution.
• Distributed task schedulerJobs, workers, and retries.

• Code smells & how to spot themcoreThe early warning signs of a decaying design.
• Refactoring techniquesExtract, inline, rename, replace-conditional-with-polymorphism.
• Anti-patterns to avoidGod object, spaghetti, golden hammer, and friends.
• Unit testing basicscoreArrange–act–assert and what makes a good test.
• Test doubles: mocks, stubs, fakesIsolating the unit under test from its collaborators.
• TDD basicsRed → green → refactor as a design tool.
• Writing testable codecoreSeams, dependency injection, and pure functions.
• Clean code principlesNaming, small functions, and comments that earn their place.
• Design & code review checklistA repeatable lens for catching problems before they ship.