THN Interview Prep

LLD / OOD Template

Every file in system-design/lld/ MUST follow this 8-section shape. Code in Go + JavaScript.

Visibility: section 3. Class Diagram (and 4. State / Sequence when used) must include at least one ```mermaid diagram so structure is visible at a glance.


# Design <Thing> (LLD)

## 1. Requirements
- **Functional**: bullets, what objects do.
- **Non-Functional**: thread-safety, extensibility, time-complexity expectations.
- **Assumptions / Out of Scope**: explicit.

## 2. Core Entities
List the nouns. For each: responsibility (one-liner) + key attributes.

| Entity | Responsibility | Key Attributes |
|--------|----------------|----------------|
| Vehicle | Represents anything parked | id, type, plate |
| Slot    | A parking spot            | id, type, occupied |

## 3. Class Diagram
Mermaid `classDiagram`. Show inheritance, composition, interfaces.

```mermaid
classDiagram
    class ParkingLot {
        +slots: Slot[]
        +park(vehicle)
        +leave(slotId)
    }
    class Slot {
        +id
        +type
        +occupied
    }
    ParkingLot o-- Slot

4. State / Sequence Diagram (where relevant)

Use mermaid stateDiagram-v2 or sequenceDiagram for the main flows (book a slot, checkout, payment).

5. Design Patterns Applied

List explicitly with why:

  • Strategy for pricing rules (link to design-patterns/behavioral/strategy.md).
  • Factory for slot creation by vehicle type.
  • Observer for slot-availability updates.

6. Implementation

Go

package parkinglot

type Vehicle struct { /* ... */ }
type Slot     struct { /* ... */ }

type ParkingLot struct { /* ... */ }
func (lot *ParkingLot) Park(vehicle Vehicle) (string, error) { /* ... */ }
func (lot *ParkingLot) Leave(slotId string) error           { /* ... */ }

JavaScript

class Vehicle { /* ... */ }
class Slot    { /* ... */ }
class ParkingLot {
    park(vehicle)   { /* ... */ }
    leave(slotId)   { /* ... */ }
}

Each class file should be self-contained enough to drop into a runnable harness. Show only the shape + critical methods, not boilerplate getters/setters.

7. Concurrency / Thread Safety

  • Where can two requests collide? (slot allocation, payment, inventory)
  • Lock granularity (per-slot mutex vs lot-wide).
  • Go: sync.Mutex, channels.
  • JS: single-threaded but async — guard with promise queues / atomic DB ops.

8. Extensibility & Followups

  • "Add EV charging slots" — Strategy + new Slot subtype.
  • "Multi-floor / multi-lot" — composite pattern.
  • "Reservation in advance" — new state in slot.
  • Edge cases (lost ticket, double payment, system crash mid-park).

Last updated on

Spotted something unclear or wrong on this page?

On this page