System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. User can reserve a parking spot
2. User can pay for a reservation
3. User can park their car on the parking spot
4. User can leave before reservation time is up
5. If user doesn't show up for reservation, then charge for first 24 hours

Non-Functional:

List non-functional requirements for the system...

1. Scalability - designing for international company with 1000s of parking lots across nations
2. Availability
3. Consistency - once reservation is made, don't allow duplicate bookings

Capacity estimation

Estimate the scale of the system you are going to design...

Assumptions:

• company operates in 10 countries
• 100 parking lots in each country
• on average, each lot has 200 car capacity
• 80% of users use it for short-term parking, averaging 4 hours
• 20% of users use for long-term parking, averaging 5 days
• each lot receives average of 200 reservations per day

Estimations:

• (10 countries) * (100 parking lots) * (200 reservation per day) = 200,000 reservations per day
• each reservation consists of:
  • unique ID
  • User ID
  • Car type
  • Reservation start time
  • Reservation end time

• assume total data per reservation is 100 bytes
• so (200,000 reservations) * (100 bytes) = 20,000,000 bytes = 20MB
• Then for 2 years, (20MB) * (365 days) * (2 years) * (1.5 growth factor) = 250 GB

RDB is a preferred solution because:

• 250GB data requirement is less than 1TB
• RDB gives strong consistency which is preferable in a transaction based system such as this
• millisecond response time not required

API design

Define what APIs are expected from the system...

APIs used by user:

• check_capacity(lot_ID, vehicle_type, start_date_time, end_date_time)
  • returns the number of parking spots available and associated prices given the parameters
• reserve_spot(user_ID, lot_ID, vehicle_type, start_date_time, end_date_time)
  • returns reservation_ID and price
  • after response user is redirected to 3rd party payment mechanism (Credit Card, Apple Pay, etc.)

• complete_reservation(user_ID, reservation_ID, payment_token)
  • verifies payment token with 3rd party payment processor (Stripe, Square, proprietary)

APIs used by gate checking service:

• vehicle_arrived(reservation_ID, date_time)
• vehicle_left(reservation_ID, date_time)

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Reservation:

• reservation_ID
• parking_lot_ID (foreign key)
• parking_spot_ID (foreign key)
• start_time
• end_time
• payment_status (paid, unpaid, canceled)
• completion_status (to be completed, fulfilled, canceled)

User:

• user_ID (primary key)
• contact_info_ID (foreign key - one-to-many)

Contact_Info:

• contact_info_ID (primary key)
• contact_type
• contact_value

Vehicle

• vehicle_ID (primary key)
• user_ID (foreign key)
• vehicle_type

Parking_Spot

• parking_spot_ID (primary key)
• parking_lot_ID (foreign key)

Parking_Lot

• parking_lot_ID (primary key)
• contact_info_ID (foreign key - one-to-many)
• capacity
• address

Transactions:

• transaction_ID (primary key)
• user_ID (foreign key)
• vehicle_ID (foreign key)
• check_in_date_time
• check_out_date_time

Don't need the `parking_lot_ID` and `parking_spot_ID` as attributes of the the `Transactions` table because vehicles reservation overlaps are not to be expected

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

API Gateway to:

• protection against DDOS
• terminate TLS
• distribute client requests to correct service node

RDB:

• stores priamry data

Redis Cache:

• store frequently used data for performance gain

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

First client will call check_capacity(), which will be handled by the Reservation Service, which reads the lot capacity information fro the database.

The client would then call reserve_spot(), also handled by the Reservation Service, which will create a new reservation in the Reservation db table.

This will create a request for payment (a redirect URI), which is returned to the client.

reserve_spot() may fail if multiple users trying to book the same spot. If error, ask client to call reserve_spot() again.

reserve_spot() will also fail if the lot is full. Should not prompt them to try again in this case. Instead can display when the lot will be available again.

Client makes the payment and sends the payment token (confirmation) via complete_reservation().

vehicle_arrived() and vehicle_left() are handled by the Transaction Service, which modifies the Transaction table to keep track of vehicle check-ins and checkouts.

Transaction Monitor service periodically checks db for non-arrivals. If user doesn't arrive within 8 hours of reservation, then reservation canceled and user charged for 24 hours.

If vehicle_left() is called before vehicle_arrived() then the admin at the lot should be notified. The service should assume the vehicle arrived around reservation start time.

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

RDB provides strong consistency. This is a transaction based service which requires consistency, so RDB over NoSQL is preferred. The estimated data over 2 years is less than 1 TB too so RDB performance won't be a concern.

NoSQL would provide better horizontal scalability, but consistency and relational queries outweigh the benefit of scalability.

Failure scenarios/bottlenecks

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

The main scalability bottleneck would be the amount of data stored and thus the database choice. All other components can be scaled because they are stateless (reservation service and transaction service) or support scalability natively (cache, API gateway).

To enhance read performance, can have READ replicas and also partition the db across nodes with logical groupings like parking lots and locations.

For fault tolerance, the database should be replicated across AZs for disaster recovery.

Monitoring systems should be in place for all servers and components.

Future improvements

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

Optimizing based on user's geographic location with a CDN like Cloudflare or using a Global Load Balancer to route client traffic to the nearest data center. Databases can also be replicated across geographic regions to ensure backups in case of a regional disaster.