Parking Lot – System Design HLD

We are going to learn a very basic problem. Being asked to me as well in the multiple system design interview. This post will help you to create a Parking Lot – System Design HLD. This will give you a fair idea on how a software system is designed.

Table Of Contents

Introduction
Non Functional & Functional Requirements (NFR & FR)
High Level Design
- Parking Lot – System Design HLD Explanation
FAQs

Introduction

First of all, we need to understand what parking lot means.

A parking lot or car park is a dedicated cleared area that is intended for parking vehicles. In most countries where cars are a major mode of transportation, parking lots are a feature of every city and suburban area. Shopping malls, sports stadiums, megachurches, and similar venues often feature parking lots over large areas.

Non Functional & Functional Requirements (NFR & FR)

We will start from the basic system which has following NFRs & FRs.

One Entry and One Exit, single floor.
CRUD operations on parking spots
- Should be able to read empty parking spot
- Should be able to remove car entry from parking spot
- Should be able to update the car details for a parking spot
  - License number, Time of entry & exit
  - Car Types: Hatchback, Sedan, SUV
  - Car Manufacturer: AUDI, BMW, Mercedese, VW, Ford, Suzuki, Fiat etc
  - Car Name
- Saving against a parking spot is not mandatory.
Issue of tickets, read off tickets, cancellation of tickets.
Payments.
Having audit is recommended.
Actors includes
- Admin: Should be able to insert the master data.
- App Users: The person who is going to use your app, he should be able to do above mentioned tasks
- Car Drivers: The person who is going to get the ticket issued, payment is done by him

We should also keep that in mind, however big the problem is, always start from MVP (Minimum Viable Product). In the interviews, always start from 0 and then moves slowly and integrate advance NFR one by one.

High Level Design

Lets start with how the user flow will be like and how the data will flow

By reading the NFRs & FRs we can see we have below major models in this.

User & type
Parking & Service
Vehicle
Ticketing & Service
Auditing

Since the User information is not required here, only vehicle and parking details. A detailed user information system is not required. Find the HLD below for the same.

Parking Lot – System Design HLD Explanation

Let us divide Parking Lot – System Design HLD into two main points, one is entry and other is exit. In entry we should provide tickets to end user by querying the DB and save / update the details accordingly. And in exit the payment is processed and vehicle is marked for exit and parking db is updated.

Vehicle Entry

The first point will be where the user will enter from left. He will then take the tickets form the parking service. After taking the tickets, the ticketing service will save all the information in one of DBs table or collection. A simple mongo db collection can also be taken into consideration as there is no much details is required to save. The information will be Vehicle details, Parking Lot Number, Timing Details. There will be one more collection which will be like key value pair, here key will be parking space id, and value will be true/false which will be updated based on occupation of it. An auditing micro service will keep on running on top of mongo collection or a queue based system can also be implement which is going to publish each insert into a queue and a subscriber can consume it. This saves all the data into insert only data warehouse which can be of any OLAP provider.

Vehicle Exit

I have called the Vehicle exit as the exit service. This exit service is going to call lots of service basically to process the payments and update the databases accordingly.

The vehicle owner will provide the parking slip to end user. He will enter the id into the system, this is going to query the same mongo collection which we inserted in above, take the details from it and then query pricing DB. Here all the pricing and payment policies are going to save.

Based on pricing policies like number of hours the car is parked, we are going to calculate the price and ask for payments.

He can select a manual payment or online payment. For manual it is a simple update once the payment is received, the barrier will be open then. For online payment service, a third party payment gateway is required like stripe or PayPal. They generally have web hooks which give confirmation of payments. Once payment is done we will open the barrier.

Again an auditing micro service will get trigger on each inserts or updates. Here I will recommend to use RDBMS for pricing db. The RDBMS will help us to maintain the ACID properties and ease of use for transactions.