System requirements

Functional:

1. The system will provide a list of hourly parking rate.
2. When a driver enters the parking lot, the system will emit a ticket and the driver can find a spot on his own.
3. When a driver leaves the parking lot, the system will process the ticket and calculate the parking fee. The system will connect to external payment system to process the payment.

Non-Functional:

1. (Availability). The parking lot system must operate 24/7. Driver can enter or leave at any time.
2. (Persistence). Ticket information should persist through restart.

Capacity estimation

Assume the parking lot has 1000 spots. At peak, there is 0.1 request/second.

For storage, there can be at most 1000 outstanding tickets. Each ticket has less than 100 byte. So we need at most 100KB. For audit purpose, we will keep ticket for 1 year, this is 36MB of data.

API design

get_rate() -> [ FeeInfo ]

reserve() -> Ticket

release(ticket_id) -> Fee

Database design

On reserve, the system will generate a ticket. On the ticket, it will record a ticket ID and the time of entry. The ticket ID can be randomly generated UUID (16 byte). The time of entry is a epoch timestamp (4 byte).

Ticket (20 byte)

• id UUID - 16 byte
• time int32 - 4 byte

For get_rate, we have a table of hourly range start and end and its hourly fee. For example, 0-2 hours is $10/hour and 2-4 hours is$5/hour.

FeeInfo

• hour range start - int32 4 byte
• hour range end - int32 4 byte
• hourly fee - f32 4 byte

High-level design

We will store current tickets in a table and used tickets in another table. This will handle the case when a UUID is reused. The FeeInfo will be in its own table.

Request flows

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

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?