Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• enter parking lot if a suitable lot is available.
• reserve ahead, users should be able to reserve a parking lot and be billed for it.
• all parking has a predetermined end time.
• inventory management. keep track of lot size and cars existing.
• pay ahead

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• should be consistent and fault tolerant.
• CP cap theorem.

Capacity Estimation

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

Lets say the lot has 500 lots.

Each lot can maybe see 1-2 cars a day.

overall capacity is 1000 transactions at most a day.

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

1. reserve
   1. req
      1. lot type
      2. time
   2. resp
      1. tiket
2. enter
   1. for non reserved spaces
3. exit
   1. req
      1. tiket
   2. resp success
   3. on exit, unlock lot
4. get availability
   1. req
      1. time slot
   2. response
      1. available lot or no.

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

1. Reservation service
   1. The core service, the bread and butter, required for most flows.
   2. serves public api on lot reservation.
   3. Data storage
      1. Reserve parking will have a bucketed hourly ticket system, user pays for the hour that they booked. penalties in exceeding. (in the ideal case we may want to buffer for the next car)
      2. non reserved storage
         1. store a shared bucket per lot type, keeps count of available lots per type.
2. Ticketing service
   1. Takes the brunt of the traffic
   2. serves public endpoint for reservations and exits.
      1. reserve
         1. pay ahead
      2. exit
         1. communicate with payment service
3. payment service
   1. hit by the ticketing service for reserve ahead
      1. redirect payment webview
   2. hit by ticketing service on exit (non reserve)
      1. calculate price, the exit machine will have an EDC

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...

The parking_spots Table

This represents the physical layout of the lot.

```

CREATE TABLE reservations (

id SERIAL PRIMARY KEY,

user_id INT NOT NULL,

spot_id INT REFERENCES parking_spots(id),

start_time TIMESTAMP WITH TIME ZONE NOT NULL,

end_time TIMESTAMP WITH TIME ZONE NOT NULL,

status VARCHAR(20) NOT NULL, -- 'PENDING_HOLD', 'CONFIRMED', 'ACTIVE', 'COMPLETED', 'CANCELLED'

created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,

-- Ensure end_time is always after start_time

CONSTRAINT chk_reservation_times CHECK (end_time > start_time)

);

```

alternative solution instead of reservasion is

CREATE TABLE spot_hourly_inventory (

spot_id INT NOT NULL,

slot_date DATE NOT NULL,

hour_block INT NOT NULL, -- 0 to 23

reservation_id INT DEFAULT NULL, -- NULL means free

PRIMARY KEY (spot_id, slot_date, hour_block)

);

0(1) query to get spor avail.

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.

Reservation system

for reserved parking spaces, there are allocated lots by id and size. user can reserve based on the lot's availability which will be stored per lot and per time slot, bookings are by the hour. buckets are populated by workers on the daily, we may want to keep reservations only up to a 3 days ahead, daily worker will always populate the 3rd day ahead. reservation system can be sharded by lot id in the future.

serves reservation availability view, on user reserve, hit the ticketing service

for the non reserved buckets, the buckets will be decremented and incremented accordingly in a transactional where we need to check if still available.

Ticketing system:

• responsible for ticket issuance
• responsible for lot reservations
• responsible for lot entry/exit
• responsible for integrating to the payment system
• on premise machines will link to this.