9.1 LLD Foundations — Quick Revision
Compact cheat sheet. Print-friendly.
How to use this material (instructions)
- Skim top-to-bottom in one pass before quizzes or interviews.
- If a row feels fuzzy — reopen the matching lesson in
README.md → 9.1.a...9.1.e.
- Drills —
9.1-Exercise-Questions.md.
- Polished phrasing —
9.1-Interview-Questions.md.
9.1.a What Is LLD
HLD vs LLD
┌─────────────┬──────────────────────────┬──────────────────────────┐
│ │ HLD │ LLD │
├─────────────┼──────────────────────────┼──────────────────────────┤
│ Scope │ Entire system │ Single service/module │
│ Focus │ Services, DBs, protocols │ Classes, methods, patterns│
│ Artifacts │ Architecture diagrams │ Class + sequence diagrams│
│ Audience │ Architects, leads │ Developers │
│ Question │ "Design Twitter arch" │ "Design parking lot LLD" │
│ Abstraction │ Very high │ Code-level │
└─────────────┴──────────────────────────┴──────────────────────────┘
Components of Good LLD
| Component | Purpose |
|---|
| Classes | Blueprint for objects — attributes + methods |
| Interfaces | Contracts — define WHAT, not HOW |
| Relationships | How classes connect — association, composition, inheritance |
| Methods | Behavior — clear names, typed params, single purpose |
| Design Patterns | Proven solutions — Strategy, Factory, Observer, etc. |
Key Principles
- Separation of Concerns — one class = one responsibility
- Open/Closed — extend via new classes, do not modify existing ones
- Depend on Abstractions — code to interfaces, not concrete classes
9.1.b OOP Fundamentals
The Four Pillars
┌─────────────────┬──────────────────────────────────────────────┐
│ Pillar │ One-liner │
├─────────────────┼──────────────────────────────────────────────┤
│ Encapsulation │ Bundle data + methods; restrict direct access│
│ Inheritance │ Child reuses parent's code ("is-a") │
│ Polymorphism │ Same interface, different behavior at runtime│
│ Abstraction │ Expose what matters, hide complexity │
└─────────────────┴──────────────────────────────────────────────┘
Access Modifiers (TypeScript)
| Modifier | Symbol (UML) | Access |
|---|
public | + | Anyone |
private | - | Only the class itself |
protected | # | Class + subclasses |
readonly | (none) | Set once in constructor |
Polymorphism Types
Compile-time (Static) Runtime (Dynamic)
───────────────────── ─────────────────
Method Overloading Method Overriding
Same name, diff params Same name, diff class
Resolved at compile time Resolved at runtime
TS overload signatures extends + override method
Abstract Class vs Interface
┌──────────────────┬────────────────────┬────────────────────┐
│ │ Abstract Class │ Interface │
├──────────────────┼────────────────────┼────────────────────┤
│ Implementation │ Yes (concrete methods)│ No │
│ State │ Yes (properties) │ No │
│ Constructor │ Yes │ No │
│ Multi-inherit │ Single extends │ Multiple implements│
│ Use when │ Shared behavior + │ Pure contract, │
│ │ enforced contract │ multiple impls │
└──────────────────┴────────────────────┴────────────────────┘
Golden Rule
Favor composition over inheritance. Use inheritance for clear, stable "is-a" relationships only. Use composition for "has-a" and when behavior needs flexibility.
9.1.c Class Relationships
Relationship Spectrum (weakest → strongest)
Dependency ┄┄► Association ── Aggregation ◇── Composition ◆──
"uses" "knows" "has-a" "owns-a"
temporary persistent weak whole-part strong, same lifetime
Quick Reference Table
┌───────────────┬────────┬──────────┬──────────────────────────────┐
│ Relationship │ Symbol │ Lifecycle│ Example │
├───────────────┼────────┼──────────┼──────────────────────────────┤
│ Dependency │ ┄┄┄► │ None │ Order uses Logger in method │
│ Association │ ───── │ None │ Teacher ↔ Student │
│ Aggregation │ ◇──── │ Weak │ Department ◇── Employee │
│ Composition │ ◆──── │ Strong │ House ◆── Room │
│ Inheritance │ ──▷ │ N/A │ Dog ──▷ Animal │
│ Implementation│ ┄┄▷ │ N/A │ Circle ┄┄▷ Shape (interface) │
└───────────────┴────────┴──────────┴──────────────────────────────┘
Aggregation vs Composition Litmus Test
Question 1: Can the PART exist without the WHOLE?
YES → Aggregation (Employee without Department = still exists)
NO → Composition (Room without House = meaningless)
Question 2: Can the PART belong to MULTIPLE wholes?
YES → Aggregation (Song in multiple Playlists)
NO → Composition (OrderLineItem belongs to ONE Order)
Code Pattern Signal
Aggregation: parts PASSED IN from outside → addEmployee(emp)
Composition: parts CREATED internally → new Room(name, area)
Multiplicity
| Notation | Meaning | Example |
|---|
1 | Exactly one | Person → 1 Passport |
0..1 | Zero or one | Student → 0..1 Advisor |
* | Zero or more | Customer → * Orders |
1..* | One or more | Order → 1..* LineItems |
m..n | Between m and n | Car → 3..5 Passengers |
9.1.d UML Diagrams
Class Box Anatomy
┌─────────────────────────┐
│ ClassName │ ← Name
├─────────────────────────┤
│ - privateField: Type │ ← Attributes
│ + publicField: Type │ (visibility + name + type)
├─────────────────────────┤
│ + method(p: T): RetType │ ← Methods
│ - helper(): void │ (visibility + signature)
└─────────────────────────┘
UML Arrows (memorize these)
Association: A ──────────── B (solid line)
Aggregation: A ◇─────────── B (hollow diamond at whole)
Composition: A ◆─────────── B (filled diamond at whole)
Dependency: A ┄┄┄┄┄┄┄┄┄┄► B (dashed arrow)
Inheritance: B ──────────▷ A (solid + hollow triangle → parent)
Implementation: B ┄┄┄┄┄┄┄┄▷ A (dashed + hollow triangle → iface)
Sequence Diagram Components
┌──────┐ ┌──────┐
│ Obj1 │ │ Obj2 │ ← Objects/Actors at top
└──┬───┘ └──┬───┘
│ │ ← Lifelines (dashed vertical)
│ message() │
│────────────►│ ← Synchronous call (solid arrow)
│ ┌┤
│ ││ ← Activation bar (processing)
│ response ││
│◄─ ─ ─ ─ ─ ─┤│ ← Return (dashed line)
│ └┤
│ │
Time flows DOWNWARD ↓
When to Use Each
| Interviewer says... | Draw |
|---|
| "Design the classes for X" | Class Diagram |
| "Walk me through the flow" | Sequence Diagram |
| "Design a parking lot" | Class Diagram FIRST, then sequence for key flows |
9.1.e LLD Interview Approach
The 6-Step Framework
┌──────────────────────────────────────────────────────────────┐
│ Step │ Action │ Time │ Output │
├───────┼───────────────────────────┼──────┼───────────────────┤
│ 1 │ Clarify Requirements │ 5 min│ Requirement list │
│ 2 │ Identify Entities │ 5 min│ Entity list │
│ 3 │ Define Classes │10 min│ Class boxes │
│ 4 │ Establish Relationships │ 8 min│ Class diagram │
│ 5 │ Define Methods + Code │10 min│ Core logic │
│ 6 │ Edge Cases + Patterns │ 7 min│ Discussion │
│ │ │ │ │
│ TOTAL │ │45 min│ │
└──────────────────────────────────────────────────────────────┘
Noun-Verb Extraction
Nouns → Candidate classes (User, Order, Product)
Verbs → Candidate methods (create, cancel, calculate)
Adjectives → Candidate enums (ACTIVE, PENDING, small, medium, large)
"Types of" → Inheritance (Car, Truck → Vehicle)
Edge Cases to Always Mention
| Category | Examples |
|---|
| Concurrency | Two users book the same seat/spot |
| Full/Empty | Lot is full, queue is empty, stock is zero |
| Invalid Input | Negative amount, null object, wrong type |
| Payment Failure | Retry? Rollback? Partial refund? |
| Not Found | User not found, ticket expired, product deleted |
Design Patterns to Mention
| Pattern | When to Mention |
|---|
| Strategy | Multiple algorithms for same task (pricing, sorting, validation) |
| Factory | Creating different subtypes based on input |
| Observer | One change triggers multiple reactions (notifications, display updates) |
| Singleton | Only one instance should exist (DB pool, config) |
| Decorator | Adding behavior without modifying existing classes (logging, caching) |
| State | Object behavior changes based on internal state (order lifecycle) |
One-Liner Definitions (20+ terms)
| Term | One-liner |
|---|
| LLD | Code-level blueprint: classes, methods, relationships, patterns. |
| HLD | System-level blueprint: services, databases, infrastructure. |
| Class | Blueprint for creating objects — defines attributes + methods. |
| Object | Instance of a class — a living entity with state and behavior. |
| Encapsulation | Bundle data + methods; control access via public methods, private state. |
| Inheritance | Child class reuses parent's code; models "is-a" relationships. |
| Polymorphism | Same interface, different behavior depending on the implementing object. |
| Abstraction | Expose only essential details; hide internal complexity. |
| Interface | Contract — defines method signatures without implementation. |
| Abstract class | Partial implementation — mix of concrete and abstract methods. |
| Association | "Knows about" — two objects reference each other, both exist independently. |
| Aggregation | Weak "has-a" — whole references parts; parts survive whole's destruction. |
| Composition | Strong "owns-a" — whole creates and owns parts; parts die with whole. |
| Dependency | Weakest relationship — temporary usage in a method (parameter or local). |
| Multiplicity | How many instances relate: 1, 0..1, , 1.., m..n. |
| UML | Unified Modeling Language — standardized diagrams for software design. |
| Class diagram | Static structure — classes, attributes, methods, relationships. |
| Sequence diagram | Dynamic behavior — step-by-step object interaction over time. |
| Visibility | Access level: + public, - private, # protected, ~ package. |
| Design pattern | Reusable solution to a common software design problem. |
| Strategy pattern | Encapsulate interchangeable algorithms behind a common interface. |
| Observer pattern | Notify dependents automatically when state changes. |
| Factory pattern | Centralize object creation; caller does not know the concrete type. |
| SOLID | Single resp., Open/Closed, Liskov Sub., Interface Seg., Dependency Inv. |
| God class | Anti-pattern: one class doing everything — violates single responsibility. |
Interview Quick-Fire Checklist
Before walking into an LLD interview, verify you can:
End of 9.1 quick revision.
← Back to 9.1 — LLD Foundations (README)