Requirements

Functional Requirements:

Booking system user can order a parking space, pay for it online, cancel it.

Gate Check-in/out Gate system records vehicle arrival and departure to reconcile usage and billing.

No show handling charge a fee if if user did not show up

Non-Functional Requirements:

Reliability when user orders parking space, this space must be saved for him

99.9%+ availability via multi-AZ deployment and failover

Scalability support 1000s lots across counties partition data by lot id

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

Booking:

order_parking(userId,lotId, timeRange, paymentDetails) orders parking space if there is available space for the time of user selected range, save payment details for later billing

cancel_parking(userId,parkingId) cancel parking if its not too late and remove any billing information for the user

record_vehicle(userId,parkingId,status) record vehicle parking status and bill user for fee if needed, process payment, mark confirmed

finalize_parking(parkingId, paymentDetails) call after order_parking — pay now, reservation confirmed, gate only handles entry/exit.

High-Level Design

System handles 1000s parking lots in different countries, system saves user parking space in specific parking lot. System gives to user possibility to cancel the order. After vehicle arrival and departure the system takes a payment and sends email to the user with all information

API Gateway / load balancer that rate-limits and routes requests

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

System handles 1000s parking lots in different countries, system saves user parking space in specific parking lot. System gives to user possibility to cancel the order. After vehicle arrival and departure the system takes a payment and sends email to the user with all information.

For database system uses PostgreSQL, because its Postgres is less expensive, and offers good features of a traditional transactional database

Two users reserve the same spot + window (race condition)

When two users attempt to reserve the same spot for overlapping times, only one can succeed. The database is the authority that decides the winner at commit time.

PostgreSQL's exclusion constraint enforces this automatically. On the reservations table:

CREATE TABLE reservations ( spot_id uuid, start_time timestamptz, end_time timestamptz, user_id uuid, EXCLUDE USING gist ( spot_id WITH =, tstzrange(start_time, end_time) WITH && ));

• WITH = on spot_id groups rows by spot
• WITH && means "time ranges overlap"

When user B's INSERT overlaps user A's committed row, Postgres rejects the insert with a conflict error. The service catches it and returns "spot unavailable" to user B — no app-level lock, no race window. This also covers the check-then-commit race: availability is re-checked inside the commit itself, so a pre-check that passed moments ago can't admit a double-booking.