Checklists & Mental Models

Applying structured processes prevents you from missing critical considerations like scale calculations, concurrency locks, and fault-tolerance patterns.

🏗️ 1. High-Level Design (HLD) Framework

Use the RESHADED framework to drive any HLD interview or system architecture task.

Clarify (R) ──► Calculate (E) ──► Schemas (S) ──► Architecture (H) ──► APIs (A) ──► Deep-Dive (D) ──► Failures (E) ──► Trade-offs (D)

HLD Step-by-Step Checklist

1. R — Requirements & Scope (5 Min)

• Action: Clarify what you are building. Ask questions to scope the problem.
• Functional: Define 3-5 critical use cases (e.g., "users can upload videos", "users can comment").
• Non-Functional: Target scale (DAU, write/read ratio), Latency budgets, Availability targets (e.g., 99.9%), and Consistency model (Strong vs. Eventual).
• Out of Scope: Explicitly list non-goals (e.g., "auth and billing are out of scope").

2. E — Estimations (3 Min)

• Action: Run back-of-the-envelope calculations. Show your math.
• QPS: Calculate average and peak write/read QPS based on DAU.
• Storage: Compute daily ingestion rate, multiply by retention period, and add a 20% replication buffer.
• Bandwidth: Estimate upload and download network throughput.
• Cache Size: Use the Pareto principle (80/20 rule) to determine memory required to cache hot data.

3. S — Storage & Schema (5 Min)

• Action: Choose your data storage layer and model.
• Choice: Pick SQL vs. NoSQL (Key-Value, Document, Wide-Column, Graph) with explicit justification based on access patterns.
• Schema: Sketch core tables/documents, primary keys, indexes, and partition keys.

4. H — High-Level Diagram (8 Min)

• Action: Draw the end-to-end data flow skeleton.
• Components: Client $\rightarrow$ DNS/CDN $\rightarrow$ Load Balancer $\rightarrow$ API Gateway $\rightarrow$ Stateless Services $\rightarrow$ Cache $\rightarrow$ DB/Blob/Queue.
• Rule: Keep components simple; focus on client request pathways first.

5. A — APIs (3 Min)

• Action: Outline the critical API endpoints.
• Protocol: REST vs. gRPC vs. GraphQL.
• Definition: List 3-4 key endpoints with HTTP method, path, request parameters, and response JSON models.

6. D — Deep-Dives (15 Min)

• Action: Detail components based on the system's unique challenges.
• Scaling: Database sharding keys, consistent hashing rings, write-caching.
• Optimization: Hotspots (celebrity problems), CDN edge caching, data indexing.

7. E — Edge Cases & Failure Modes (3 Min)

• Action: Detail how the system handles partition failures and server crashes.
• Checks: Database replica lag recovery, rate-limiter fallback, message queue backpressure, cache thundering herd mitigations.

8. D — Done (Trade-offs) (3 Min)

• Action: Conclude by summarizing key trade-offs.
• Trade-offs: CAP theorem choices (e.g., AP vs CP), read vs write latency balances, cost vs reliability compromises.

💻 2. Low-Level Design (LLD) / OOD Framework

LLD translates business requirements into clean, testable, object-oriented code structures.

LLD Class Layout Map

Client request ──► [ Controller ]
                         │
                         ▼
                  [ Service Interface ]
                         │
                         ▼
             [ Concrete Service Implementation ] ◄──► [ Design Patterns ]
                         │
                         ▼
                [ Repository / DAO ]
                         │
                         ▼
                 [ Domain Entities ]

LLD Step-by-Step Checklist

1. Define Domain Entities & Value Objects

• Action: Identify core data classes.
• Entities: Classes with unique IDs and mutable state (e.g., User, ParkingSlot, Order).
• Value Objects: Immutable classes defined solely by their attributes (e.g., Address, Money, Coordinates).

2. Apply SOLID Principles

• Single Responsibility (SRP): Split classes so each handles exactly one function (e.g., decouple InvoiceGenerator from PaymentProcessor).
• Open/Closed (OCP): Use interface abstractions. For example, implement a PaymentStrategy interface so you can add new payment gateways without modifying checkout code.
• Liskov Substitution (LSP): Subclasses must not break parent contracts. Avoid throwing UnsupportedOperationException in subclasses.
• Interface Segregation (ISP): Define small, focused interfaces rather than bloated ones.
• Dependency Inversion (DIP): Inject dependencies via constructor injection using abstractions/interfaces rather than instantiating classes directly (new ConcreteService()).

3. Select Appropriate Design Patterns

• Builder: For classes with complex initialization parameters (e.g., MealBuilder, UserQueryBuilder).
• Factory Method: For instantiating subclasses dynamically (e.g., creating a Sedan vs SUV in a parking lot system).
• Strategy: For swapping out algorithms at runtime (e.g., charging rates by hour vs day).
• State: For managing complex state flows (e.g., vending machine states: NoCoin, HasCoin, Dispensing).
• Observer: For broadcasting events to listeners (e.g., notifying riders of driver location updates).

4. Design for Concurrency & Thread Safety

• Identify Mutability: Locate collections or variables shared across threads (e.g., lists of free parking slots).
• Locks: Use synchronized methods/blocks or ReentrantLock for exclusive access.
• Thread-Safe Collections: Utilize concurrency-safe wrappers (e.g., ConcurrentHashMap, CopyOnWriteArrayList).
• Atomic Variables: Use AtomicInteger or AtomicBoolean for low-overhead, lock-free operations.