What design patterns did you apply in the parking lot design and why?
Fast recall
Quick revision
Core answer
Depth of design pattern knowledge and ability to justify pattern choices with concrete benefits specific to the parking lot domain.
Listing patterns without explaining why they're needed or applying them where simpler solutions would suffice, showing pattern obsession over pragmatism.
Contrast each pattern with the problem it solves—explain what would break or become unmaintainable without the pattern.
Interview-ready guide
Interview answer
I would name patterns only where a requirement creates a design pressure. Strategy fits fee calculation when the system has hourly, event, weekend, or vehicle-specific policies. The exit service depends on a FeePolicy, so a new pricing rule does not add another branch to ParkingLot.
Observer or a domain event fits display boards. After a spot change commits, interested boards receive an occupancy event instead of the spot holding references to every display. Factory is useful if vehicle creation parses external input or applies setup rules; otherwise constructors are clearer. Builder is useful when a ticket has many optional or staged fields, but a small immutable record may be enough.
I would explicitly avoid using Singleton as the consistency mechanism. It limits instances only within one JVM and hides dependencies. One physical lot can be represented by an injected aggregate or a repository id, while a conditional database update, version check, or lock protects a spot when several application instances compete for it.
What design patterns did you apply in the parking lot design and why
Direct Answer
Singleton ensures one ParkingLot instance system-wide. Strategy decouples fee calculation from parking logic, allowing runtime swaps. Observer updates DisplayBoards when spot status changes without tight coupling. Factory Method creates Vehicle subclasses, centralizing instantiation. Builder constructs complex ParkingTicket objects with optional fields cleanly.
Deep Dive & Architecture
Strategy isolates a changing price rule
FeePolicy lets hourly, flat, event, or weekend pricing vary without changing the exit workflow. Factory is useful only when vehicle or spot creation includes validation or configuration; ordinary constructors are clearer when creation is trivial.
Observer separates occupancy from displays
A committed spot change can publish an event that display boards consume. The spot does not need a reference to every board. In a single process this may be a small observer list; across services it may be a message. Either design must handle unsubscribe, retries, or stale displays according to its scope.
Do not use Singleton as a consistency mechanism
One physical parking lot can be represented by one injected aggregate or repository identity. A Singleton only limits objects inside one JVM and cannot stop two servers from claiming the same database row. Atomic spot reservation belongs in the spot or persistence boundary. Builder is useful for a ticket only when construction is genuinely complex; otherwise a constructor or record is simpler.
Code Example
interface FeePolicy { Money calculate(ParkingTicket ticket, Instant exit); }
record SpotOccupancyChanged(String spotId, boolean occupied) {}
interface OccupancyListener { void onChange(SpotOccupancyChanged event); }
class ParkingLot {
private final FeePolicy feePolicy;
private final List<OccupancyListener> listeners;
ParkingLot(FeePolicy feePolicy, List<OccupancyListener> listeners) {
this.feePolicy = feePolicy;
this.listeners = List.copyOf(listeners);
}
void spotChanged(ParkingSpot spot) {
var event = new SpotOccupancyChanged(spot.id(), spot.isOccupied());
listeners.forEach(listener -> listener.onChange(event));
}
}
Common Mistakes & Pitfalls
- Pattern-name bingo — explain the change or coupling problem before naming a pattern.
- Singleton as shared-state safety — it does not coordinate several JVMs and makes tests depend on global state.
- Observer before commit — a board should not announce a spot change that later rolls back.
- Factory or Builder for trivial construction — direct constructors and records are often clearer.
Check your understanding
Answer these without looking back at the article.
- Design a parking lot system. Walk me through your approach.
- How does the fee calculation work in your parking lot design?
- How would you extend the parking lot design for multiple locations?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.