Deep Dive

🧠 1. Design Tradeoffs

⚖️ 1. Simplicity vs Performance

Choice made:

Used Queue per SpotType → O(1) allocation

Tradeoff:

✅ Fast allocation
❌ No guarantee of nearest spot

Alternative:

Use PriorityQueue (distance-based)
- ✅ Better UX (nearest spot)
- ❌ Slightly higher complexity (log n)

⚖️ 2. Global Lock vs Fine-Grained Locking

Choice made:

synchronized at ParkingLotManager
ReentrantLock at floor level

Tradeoff:

✅ Easy to implement, safe
❌ Limits parallelism under heavy load

Alternative:

- Lock per SpotType or even per ParkingSpot✅ Better concurrency
- ❌ More complex, risk of deadlocks

⚖️ 3. In-Memory Storage vs Persistent Storage

Choice made:

HashMap<String, ParkingTicket> (in-memory)

Tradeoff:

✅ Fast, simple
❌ Data loss on crash

Alternative:

Database-backed storage
- ✅ Durable
- ❌ Latency + infra complexity

⚖️ 4. Floor Iteration Strategy

Choice made:

Sequentially check floors

Tradeoff:

✅ Simple
❌ Not optimal for large systems

Alternative:

- Maintain global availability indexFaster lookup
- More bookkeeping

🧩 2. SOLID Principles Check

✅ S — Single Responsibility Principle

✔ Mostly followed:

ParkingFloor → manages spots
ParkingLotManager → orchestrates parking
PricingStrategy → fee logic

⚠️ Minor issue:

ParkingLotManager does multiple things:
- allocation + ticketing + orchestration

👉 Improvement:

Split into:
- SpotAllocator
- TicketService

✅ O — Open/Closed Principle

✔ Well followed:

Add new pricing → implement PricingStrategy
Add new vehicle → extend Vehicle

❌ Slight violation:

Spot preference logic uses switch

👉 Improvement:

Move logic into:


vehicle.getAllowedSpotTypes()

✅ L — Liskov Substitution Principle

✔ Fully followed:

Car, Truck can replace Vehicle
SmallSpot, LargeSpot behave consistently

✅ I — Interface Segregation Principle

✔ Good:

PricingStrategy is clean and minimal

Could improve:

Introduce smaller interfaces like:
- Allocatable
- Billable

⚠️ D — Dependency Inversion Principle

Partially followed:

Depends on PricingStrategy abstraction ✅

But:

ParkingLotManager directly depends on ParkingFloor

👉 Improvement:

Introduce:


interface SpotAllocator

🚀 3. Scalability & Extensibility

📈 Scaling the System

Current Limitations:

Single JVM (in-memory)
Sequential floor scan
Coarse locking

✅ How to Scale

1. Horizontal Scaling

- Move to microservicesParking Service
- Ticket Service
- Payment Service

2. Database Integration

Store:
- Tickets
- Spot states
Use:
- Redis → fast availability lookup
- SQL → durability

3. Distributed Locking

Use:
- Redis locks
- Zookeeper

4. Event-Driven Architecture

Emit events:
- VEHICLE_PARKED
- VEHICLE_EXITED

🧱 Extensibility

Easy to Extend:

✅ Add new pricing:


class WeekendPricing implements PricingStrategy

✅ Add EV charging spots:

Add EVSpot extends ParkingSpot

✅ Add reservations:

Add ReservationService

🔮 4. Future Improvements

🅰️ 1. Smarter Allocation

Nearest spot (distance-based)
Priority queue per entry gate

🅱️ 2. Multi-Entry Gate Support

Each gate:
- Has its own allocator
- Maintains local view

🅲 3. Real-Time Display Boards

Show:
- Available spots per floor
Use observer pattern

🅳 4. Fault Tolerance

Backup ticket store
Recovery mechanism

🅴 5. Payment Integration

Add:
- UPI / Card / Wallet
Separate PaymentService

🅵 6. Analytics

Occupancy rate
Revenue trends
Peak hours

🏁 Final Interview Summary (Say This)

👉 “The design prioritizes simplicity and O(1) allocation using queues, while maintaining extensibility through strategy patterns. It adheres well to SOLID principles with minor improvements possible around SRP and DIP. For scaling, we can move to distributed services with caching and event-driven architecture. The system is easily extensible for features like reservations, EV spots, and dynamic pricing.”

Submissions

Displaying Solutions with Scores Ranging from 1 to 10