What are the most useful design patterns to know for LLD interviews?

Direct Answer

The most useful design patterns for LLD interviews are: Singleton for ensuring one shared instance (like ParkingLotManager), Strategy for interchangeable algorithms (different pricing strategies), Observer for event notification (notify users when spots are available), Factory for creating objects without specifying exact class (VehicleFactory creates Car or Motorcycle), Builder for constructing complex objects step-by-step (ParkingLotBuilder), and Decorator for adding features dynamically (adding VIP features to a ParkingSpot).

Deep Dive & Architecture

Design pressure and matching pattern

Strategy fits interchangeable rules such as parking fees or discount calculation. Observer fits one event with several independent listeners, such as a freed spot updating display boards. Factory fits object creation that depends on input or setup rules. Builder helps construct an object with many optional values or a staged validation process.

State and Command solve behavioural problems

State is useful when allowed operations change with a lifecycle, such as an ATM session or order. Command represents an action as an object when it needs queuing, retries, auditing, or undo. These patterns add more classes, so the requirement should justify that cost.

Treat Singleton with caution

One real-world resource does not automatically require a global Java object. Dependency injection can create one application-scoped instance without hiding dependencies, and a database or distributed lock—not Singleton—protects shared state across application instances. A useful interview answer explains one concrete pressure, shows how the pattern changes the classes, and names when the simpler direct design would be better.

Code Example

class VehicleFactory {                          // Factory: hide concrete class choice
    static Vehicle create(VehicleType t, String plate) {
        return switch (t) {
            case CAR -> new Car(plate);
            case TRUCK -> new Truck(plate);
            case MOTORCYCLE -> new Motorcycle(plate);
        };
    }
}
// Builder: readable construction with optionals
ParkingTicket t = new ParkingTicket.Builder()
        .vehicle(car).spot(spot).entry(LocalDateTime.now())
        .build();

Common Mistakes & Pitfalls

• Pattern obsession — forcing a Factory on a two-class hierarchy. Patterns are tools, not goals.
• Singleton everywhere — it's global state; overuse hurts testability.
• Naming a pattern without its problem — say why it's needed.
• Builder for two fields — a constructor or record is clearer; Builder shines with many optionals.