Requirements

Functional Requirements:

• Allow reservation of a parking spot.
• Process payment for the reservation.
• Enable parking of a car in the reserved spot.
• Support early departure before reservation time expires.
• Gate check-in/out.
• Handle no show.

Non-Functional Requirements:

• Low latency
• Can handle concurrency issues
• Security concerns for payment processing
• Scale to up to 100,000 or more lots

API Design

The api need to handle at minimal booking and check in and check out, these should be handled by different services to prevent one service from impacting the other.

For this question assuming parking lots may have widely different geographic locations we can split data based on location (geographic data split).

More frequently used parking lots will be cached to lower latency when booking.

Concurrent booking is also a concern and such, locking will be used for users to finished their booking and payment process. A race condition will be put in the DB if a parking spot is requested at the same time.

High-Level Design

A load balancer and then an api gateway to both the booking and check in check out system. Assuming the gates are provided by a third party gate company, the check in check out system will receive http post requests from the gate with the license number and time of check in.

The systems will then update the DB on request reading and writing through the cache to ensure data consistency.

DB scaling will be handled through geographic locations where adding new dbs in new geography and sharding by geographic location(amount of parking lots in one geographic region is not likely to grow, parking lot data can be deleted after some sort of TTL period)

5

Detailed Component Design

Because in this case we value data consistency over latency on write (booking doesn't need instant completion) we will use a synchronous operation to write through cache and the DB. We want to write to cache if the parking lot data was taken from it.

A locking system will be used on lot space. Requested lot space will be locked for the user to finish the payment walk through.

Because most operations will be write operations, we will use geographical sharding to scale DB as parking lots grow and reduce latency (as you are very likely to be accessing services physically close to parking lots). Load balancer will also balance based on IP address (if and when scaled to multiple web service across the globe)