Low Level Design

A parking-lot LLD is an object model for floors, slots, vehicles, tickets, and fees — not a database schema. You assign a free slot (often nearest), issue a ticket on entry, and compute a fee on exit by vehicle type. Strategy fits pricing; do not bury vehicle rules in a giant switch on the lot. The interview is class boundaries and relationships, then a simple assign/exit flow.

An elevator system takes hall and cabin requests and moves cars without randomly reversing mid-trip. State (idle, moving up/down, maintenance) plus a dispatch strategy for multiple cars is the usual design. Start with one car and SCAN-like direction, then add a controller that assigns requests. The hard part is request queues and direction, not drawing cables.

Tic-tac-toe is a Game that owns a Board and Players and applies Moves. Win detection should run from the last move (row/col/diag), not a full scan every time if you can avoid it. Design the board so N×N / K-in-a-row is a parameter, not a rewrite. Optional undo is a stack of moves. Keep UI out of the domain objects.

Snake and ladder is a turn-based Game: roll dice, move a Player along a Board, then jump if the cell is a snake or ladder. The board is data (start → end map), not if (position == 14). Decide exact-win vs bounce at the end. Multiple players are a list and a turn index. No design pattern is required — clear OOP is the bar.

A library LLD separates Book (ISBN, title) from BookItem (physical copy with barcode). Members borrow items via Loans with due dates and fines; a Catalog searches by title/author/ISBN. Librarian vs member is a role, not a second copy of the whole model. The trap is treating every copy as the same Book object so you cannot track who has which copy.

Splitwise records an Expense paid by someone and Split among users (equal, exact, percent — Strategy). A BalanceSheet stores how much A owes B after many expenses. Get pairwise balances right before “simplify debts” (min cash-flow). Do not start from the graph algorithm; start from User, Expense, Split, and an invariant that splits sum to the total.

A vending machine is a State machine: idle, has money, dispensing, sold out, cancelled. Each action (insert coin, select, refund) is valid in some states only — that is the State pattern. Inventory holds items and prices; change is computed on success. The interview is “you cannot dispense with no money” encoded in types/states, not a pile of booleans.

An ATM session authenticates a card (PIN via a BankService you mock), then withdraws or shows balance. CashDispenser hands out notes (often chain of denomination handlers). Treat the bank as an interface — the machine should not own accounts. State covers idle → card in → authenticated → eject. Cancel and errors must eject the card; that is part of the model.

Car rental is inventory of Vehicles at a Store plus Reservations that block a vehicle for a date range. The hard invariant is no overlapping bookings for the same car. Pricing is a Strategy by vehicle type or duration. User, Reservation, Bill are separate from the vehicle catalog. Model the interval explicitly; do not hope two bookings “probably” do not clash.

Movie booking is Theatre → Screen → Show → Seats, plus a Booking that holds seats until payment or timeout. Two users must not confirm the same seat — that is the interview (lock/hold with expiry, then confirm). Pricing and payment are supporting pieces. Design the seat lock before UI. Concurrency is the problem; a class diagram without locks is incomplete.

Chess LLD is a Board of Pieces where each piece type implements its own legal moves (polymorphism/Strategy), plus turn taking. Do not build an engine or full checkmate search unless asked. Optional check detection is “does this move leave the king in attack.” Scope honestly: object model and move API, not Stockfish.

A logger accepts a LogRecord (level + message), formats it, and fans out to Appenders (console, file). Levels filter; you add an appender without editing Logger (OCP). Chain of Responsibility or a list of appenders both work; Observer is the same idea. Singleton is optional and often overused. The test is: new destination, no rewrite of the log() method.