Requirements

Functional Requirements:

• User is able to enter his vehicle to parking
• User is able to exit the parking
• User is able to pay for the parking
• release spot if not checked in within X min
• User can do a parking allocation

Non-Functional Requirements:

• system has to be able to identify the cars by the RFID for security
• system should be responsive and reliable with read <200 ms
• system should be able to scale
• idempotency & consistency

Capacity Estimation

10 countries, 100 lots, each lot has 500 spots,

in total 500000 spots and turn over of 2 per day, which makes it 1M reservations per day,

• Write QPS avg: 1M/86400 = 12 writes/sec
• peak: avgx3 = 36writes/sec
• reads dominate: 10:1 --> 350 read QPS
• 128 bytes × 1M/day × 365 × 2 ≈ 93 GB

API Design

We would have a few endpoints, one for the GET /lots/{id}/availability

it returns 200 with a list of available spots cacheable

another POST /reservation to hold the reservation with TTL in case the driver doesn't show up and POST /reservation/{id}/confirm to finalize the booking

when a car enters a message will be published to the topic and another one when it exits

High-Level Design

in case of conflict, we only book a slot when it has a free status and we check before we act and the booking has a TTL it expires after x minutes

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.