System requirements

there are 2 main types of users for the system:

1. Drivers - they will have 2 main usages
   1. Near-me parking - based on their specification and location they will search for parking space near them
   2. Reserve a parking - they will reserve a parking based on specification and location for few hours
2. Parking lots operators
   1. Manage and improve efficacy in their parking lots

In order to make this system work we need quite a few parking lots operators to sign up, as the drivers will only use the features to find parking.

So the suggestion is to go to a Municipality and convince them to use their parking lot for this startup.

Functional:

• User (driver) can create/edit/delete profile (including vehicle specification - and allowing choice multiple vehicles)
• User (driver) can book a parking for time window and location
• User (driver) can search for available parking near a location and then reserve it
• User (parking lot) can create/edit/delete a profile (including all parking types - size, disabled, in sun and so on)
• User (parking lot) can view their parking lot in dashboards in order to analyze data

Non-Functional:

• Scalability - we anticipate huge growth in both types of users
• Availability - the best feature of a system, if it isn't up users lose trust

Capacity estimation

We will start by designing for municipality parking - (and maybe a few private operators) in a city of 100,000 population. So about 30-70 parking lots in the city. And about 20,000 drivers in peak hours.

We will need to store data about each driver (2MB) and about each parking lot (50MB)

So we need about ~40GB storage for drivers, and about 1GB for parking lots. So storage wise we will need about 60GB of storage (to handle sudden growth).

We expect about max of 20,000 requests in peak hour so it is about 500 requests per minute. Since most requests will be about finding a parking near me, we will have most of the data and they will only send their ID and location. So bandwidth wise we wont be needing much. Lets say 50Mbps.

API design

• CRUD for drivers - create profile + vehicle specification
• CRUD for parking lots - create parking + price
• FIND near parking - using location and vehicle specification
• RESERVE parking - using time window and driver ID

Database design

Tables:

1. Drivers (driver_id, name, email, hashed_password).
2. Vehicles (driver_id, driver_id, type, size, is_disabled_vehicle).
3. ParkingLots (lot_id, location (PostGIS GEOGRAPHY), capacity, hourly_rate, metadata (JSON)).
4. ParkingSpots (spot_id, lot_id, type, size, is_reserved).
5. Reservations (reservation_id, driver_id, spot_id, start_time, end_time).

Indexes:

• Geospatial index on ParkingLots.location.
• Composite index on Reservations(start_time, end_time) for availability checks.

High-level design

Architecture: Microservices with API Gateway, Load Balancers, Caching, and Geospatial Database

Components:

1. API Gateway: Routes requests to services, handles authentication, rate limiting.
2. User Service: Manages driver/parking lot profiles (CRUD).
3. Parking Lot Service: Handles parking lot metadata (e.g., size, disabled spots).
4. Search Service: Finds nearby parking using geospatial queries.
5. Reservation Service: Manages bookings with concurrency control.
6. Analytics Service: Generates dashboards for parking operators.
7. Database: PostgreSQL + PostGIS (geospatial queries), Redis (caching).
8. CDN: Hosts static assets (parking lot images).

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Search Service

• Geospatial Query: Uses PostGIS ST_DWithin to find lots within radius.
• Caching: Redis caches frequent queries (e.g., "downtown parking") for 5 minutes.
• Filtering: Excludes lots without matching vehicle specs (e.g., truck height).

Reservation Service

• Concurrency Control:
  • Pessimistic locking via Redis SETNX (prevent overbooking).
  • Database transaction:
  • sql
  • Copy

• Scalability: Shard reservations by lot_id (e.g., 10 shards for 70 lots).

Trade offs/Tech choices

1. PostgreSQL over NoSQL: Ensures ACID compliance for reservations. PostGIS simplifies geospatial queries.
2. Redis for Caching: Reduces latency for high-traffic search queries.
3. Microservices: Isolates failures but adds complexity (mitigated with Kubernetes).

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?