Loading...
1. Manage vehicle entry and exit through parking gates.
2. Generate a unique parking ticket for each vehicle.
3. Identify the vehicle type and assign a suitable parking spot.
4. Track parking spots as available, occupied, reserved, or unavailable.
5. Support multiple floors, parking zones, and entry/exit gates.
6. Provide real-time parking availability by floor, zone, and vehicle type.
7. Record vehicle entry time, exit time, parking spot, and ticket details.
8. Calculate parking fees based on duration, vehicle type, and configurable pricing rules.
9. Support multiple payment methods such as cash, card, and digital payment.
10. Validate tickets and payments before allowing vehicle exit.
11. Release the parking spot after the vehicle exits.
12. Support parking spot reservations and prevent conflicts with existing reservations.
13. Allow administrators to add, remove, and manage parking spots and floors.
14. Allow administrators to configure parking rates and pricing rules.
15. Maintain parking, ticket, reservation, and payment records.
16. Provide occupancy and parking reports for administrators.
1. Availability – The system should be highly available, especially during peak parking hours.
2. Performance – Parking spot availability, ticket generation, and fee calculation should respond within a few seconds.
3. Scalability – The system should support increasing numbers of vehicles, parking spots, floors, and locations.
4. Reliability – The system should accurately track parking spots, tickets, vehicles, and payments without data loss.
5. Consistency – A parking spot should not be assigned to multiple vehicles at the same time.
6. Security – User, vehicle, ticket, and payment information should be protected from unauthorized access.
7. Fault Tolerance – The system should continue operating when individual components such as a parking gate, server, or database instance fails.
8. Data Durability – Parking and payment records should not be lost in case of system or hardware failures.
9. Maintainability – The system should be modular and easy to update, debug, and maintain.
10. Observability – The system should provide logs, metrics, monitoring, and alerts for failures, traffic, occupancy, and payment issues.
11. Disaster Recovery – The system should support backups and recovery mechanisms in case of major system failures.
12. Concurrency – The system should correctly handle multiple vehicles entering, exiting, or requesting parking spots simultaneously.
13. Extensibility – The system should allow new vehicle types, payment methods, pricing rules, and parking features to be added easily.
14. Usability – The system should provide a simple and intuitive experience for drivers, parking staff, and administrators.
15. Auditability – Important operations such as ticket creation, spot assignment, payment, and vehicle exit should be recorded for auditing and troubleshooting.
For a first system-design exercise, we can estimate the scale by making reasonable assumptions for a busy city parking
lot. Assume the system manages 2,000 parking spots and serves around 10,000 vehicles/day. Each vehicle generates at
least one entry and one exit transaction, resulting in approximately 20,000 write operations/day.
Parking availability is read frequently by drivers and parking gates, so we can assume a 10:1 read/write ratio,
giving roughly 200,000 reads/day. This translates to an average of about 2–3 reads/sec and ~0.25 writes/sec,
while designing for 10× peak traffic, resulting in approximately 25 QPS for reads and 3 QPS for writes.
1 /api/v1/parking-lots/{lotId}/availability GET Get available parking spots by type/floor
2 /api/v1/vehicles/entry POST Register vehicle entry and create a parking ticket
3 /api/v1/tickets/{ticketId} GET Get ticket and parking details
4 /api/v1/parking-spots/{spotId} GET Get status/details of a specific parking spot
5 /api/v1/tickets/{ticketId}/fee GET Calculate the current parking fee
6 /api/v1/payments POST Process parking payment
7 /api/v1/vehicles/exit POST Process vehicle exit and release the parking spot
8 /api/v1/reservations POST Reserve a parking spot
9 /api/v1/reservations/{reservationId} GET Get reservation details
10 /api/v1/reservations/{reservationId} DELETE Cancel a reservation
11 /api/v1/parking-lots/{lotId}/spots POST Add a new parking spot — Admin
12 /api/v1/parking-spots/{spotId} PATCH Update spot status/type — Admin
13 /api/v1/parking-lots/{lotId}/pricing PUT Configure parking rates — Admin
14 /api/v1/parking-lots/{lotId}/reports GET Get occupancy/revenue reports — Admin
flowchart LR
U[User / Parking Gate]
LB[Load Balancer]
AG[API Gateway]
BS[Backend Services]
R[(Redis)]
DB[(Database)]
MQ[Message Queue]
PG[Payment Gateway]
MON[Monitoring / Logging]
U --> LB
LB --> AG
AG --> BS
BS --> R
BS --> DB
BS --> PG
BS --> MQ
MQ --> MON
BS --> MON
erDiagram
PARKING_LOT ||--o{ FLOOR : contains
FLOOR ||--o{ PARKING_SPOT : contains
VEHICLE ||--o{ PARKING_TICKET : has
PARKING_SPOT ||--o{ PARKING_TICKET : assigned_to
PARKING_TICKET ||--o| PAYMENT : has
VEHICLE ||--o{ RESERVATION : makes
PARKING_SPOT ||--o{ RESERVATION : reserved_for
PARKING_LOT ||--o{ PRICING_RULE : defines
PARKING_LOT {
bigint lot_id PK
string name
string address
int total_spots
string status
datetime created_at
}
FLOOR {
bigint floor_id PK
bigint lot_id FK
string floor_number
int total_spots
}
PARKING_SPOT {
bigint spot_id PK
bigint floor_id FK
string spot_number
string spot_type
string status
}
VEHICLE {
bigint vehicle_id PK
string license_plate UK
string vehicle_type
datetime created_at
}
PARKING_TICKET {
bigint ticket_id PK
bigint vehicle_id FK
bigint spot_id FK
datetime entry_time
datetime exit_time
decimal amount
string status
}
PAYMENT {
bigint payment_id PK
bigint ticket_id FK
decimal amount
string payment_method
string status
string transaction_id
datetime paid_at
}
RESERVATION {
bigint reservation_id PK
bigint vehicle_id FK
bigint spot_id FK
datetime start_time
datetime end_time
string status
}
PRICING_RULE {
bigint pricing_id PK
bigint lot_id FK
string vehicle_type
decimal hourly_rate
decimal daily_max
datetime created_at
}
| **Primary Database** | PostgreSQL/MySQL |
| **Cache** | Redis for parking availability |
| **Concurrency** | Distributed lock or database row-level lock |
| **Messaging** | Message Queue for asynchronous events |
| **Service Scaling** | Stateless services + Load Balancer |
| **Reliability** | Idempotent entry/exit/payment operations |
| **Critical Requirement** | Never assign the same parking spot to two vehicles |
| **Estimated Peak Load** | ~25–30 QPS based on earlier capacity estimation |
| **Storage** | ~7–8 GB/year for core parking transaction data |