System requirements


Functional:

The parkin lot has to manage vehicle entry, exit and parking allocation.

It has to manage different types of vhicles.


The parking lot system also has to:

  • Provide good user experience
  • Manage space efficiently


Non-Functional:

The parking lot system also has to:

  • Be secure
  • Reduced latency for entry an exit (< 1 s)
  • High availability so users can enter and exit the parking lot


Assumptions:

  • Tickets stored for 5 years
  • Parking spots have sensors that:
    • Detect vehicle pressence
    • Inform of available spot with a green light when spot is available for helping users find free slots, improving customer experience and improving efficiency
  • At entrance both plate number and vehicle type, based on its size, are identified for improoving user experience and space optimization
  • Eventual consistency for reads is acceptable because once a vehicle enters it takes some time until that information is neede for read


Capacity estimation

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


200 parking spots

200 parking inputs / outputs (tickets) --> 73.000 tickets / year --> 365.000 tickets in 5 years






API design

Define what APIs are expected from the system...


Vehicle entry

  • input: number plate, vehicle type
  • output: ticket id, recommended parking floor and area

A new ticket is created for the number plate and vehicle type

Parking slots are queried to find recommended area based on vehicle type


Parking slot state changed

  • input: parking slot id, state

Once a sensor detects a slot stat chenage, this API is executed to update it in the database

It's used when a vehicle enters a parking spot and when it leaves it


Parking payment amount calculation

  • input: ticket id
  • output: amount to pay

Computes the amout to pay based on the actual time and when the vehicle entered


Parking payment

  • input: ticket id
  • output: ok?

Called to confirm ticket payment updating ticket payment state to allow the carr to leave the parking lot


Vehicle exit

  • input: number plate
  • output: allowed

When the vehicle wants to exit the parking lot, it checks that the ticket has been payed and stores the exit date and time


Database design


Database entities (MongoDB collections)

  • Parking ticket (60 B)
    • ticket id: 8 B
    • plate Number: 10 B
    • vehicle type: 10 B
    • entrance date: 8 B
    • isPayed: 1 B
    • payment amount: 5 B
    • exit date: 8 B
  • Parking slots (40 B)
    • floor: 4 B
    • slot number (in the floor): 4 B
    • parking area: 15 B
    • vehicle type: 10 B
    • free: 1 B



Database space

  • Ticketrs: 365.000 * 60 < 50 MB
  • No high read or write throughput
  • Even including indexes the space will be reduced


Database choice

A NoSQL document DB is selected because:

  • High availability is the main non functional requierement
  • No complex queries nor complex strict sqhema is requiered
  • Eventual consistency for reads can be used with no transactional requierements


Mongo DB is selected as a mature and well known option by developers and sysadmins


Database modeling

Indexes

  • Parking ticket: plate number, entry date
  • Parking slots:
    • floor, slot: for updating slot state
    • vehicle type, free: for finding free slots


High-level design


Main components

Load balancer

Redirects requests to an available application server



Application serveer

Execute the system services that handle requests and implement systme functionality accessing the database.


Database

Stores tickets and parking spots status in order to provide system functionality


Analytical system

Stores information that allow the business to analyze the behaviour and plan improvements. For example to understand if some vehicle types don't have enough spots or if vehicles park in the right position



Monitoring system

Stores:

  • monitoring metrics both:
    • business: for business information. Example: % spots in use by vehicle type. Allows the monitoring from a business perspactive. Can also trigger alerts in case of thresholds exceeded
    • technical: to understand system health and behaviour. Alows to trigger alerts in case of problems. Example: latency, component errors or unavailability
  • aplication logs that enable problem solving




User experience

  • Information about available spots (floor and number)
  • Recomends upper floor with 5%


Security

  • Exit barrier only opens if the ticket has been payed --> avoid vehicle stealed exit without having the ticket




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



Vehicle entry

The vehicle is at the parking barrier.

The parking barrier identifies the plate number and vehicle type and calls vehicle entry service.

The vehicle entry services:

  • creates a ticket
  • retrieves information about free slots for that type and recommends a parking area


Parking slot state changed

When the vehicle parks in a spot, the spot ussage sensor calls the parking slot state change service with it's number and floor indicating it has been used



Parking payment

The user enters tha parking ticket in the teller machine

The teller machine calls the payment amount calculation service with the tichket id

The payment amount calculation service returns the amount to pay taking into account the entry time and the current time and returns it

The teller machine shows the amount to pay and the user pays it

The teller machine calls the parking payment service with the ticket id, and the service updates the ticket as peyed


Vehicle exit

When the vehicle approaches the exit barrier, the barrier calls to the vehicle exit service with the number plate, the service checks if the ticket has been payed and, in that case, opens the barrier


Detailed component design


Load balancer

A L3 load balancer is selected becauese:

  • No external users access the system, only internal elements
  • The number of requests is quite small
  • No intellingent routing / probes, nor content management are needed
  • L3 are cheaper than L7 load balancers

The main objective is to provide availability in case of an application server fails.

The load balancer will also be in a high availability configuration

Nginx in two servers with active-passive failover is selected




MongoDB database

For warantiing availability a replicaset with 3 nodes, in 3 different availability zones, and 5 replicas is used, allowing for a complete failure of a datacenter without service lost.

With the reduced number of requests expected, a cloud small NoSQL database could be used, for example AWS DynamoDB to reduce costs. MongoDB is preferred because:

  • No scaling needs are forseen because parking can't increase parking lots
  • There are multiple components located on premises: parking barriers, sensors and teller machine


Trade offs/Tech choices


The load of the system is very low, both for readings and writtings, so no cache will be implemented as it increases costs without a clear benefit.


For the same reason a L3 load balancer with fail-over configuration (active-passive) will be used.


Failure scenarios/bottlenecks

The system has been design to have high availability. Even though, in case of a failure or an security emergency, the system is prepared to:

  • open output barriers and allow free exit without ticket payment checking
  • forbid vehicles entering the parking lot


The number of requests to the system is very low so no bottleneck is expected


Future improvements

In order to avoid having its own hardware resources and administration, a cloud solution could be implemented:

  • a VPN can be established to protect communications to the cloud and with redundancy for high availability
  • managed services can be used. For example DynamoDB instead of MongoDB
  • as the resources are very small, serverless solutions can also be considered to reduce the IT costs


Analyitical system that helps to understand if vehicles use their appropiate slots and help to detect usage of biger slots than needed and define measures to reduce it improving efficiency.


For improving user experience, an automatic charging system, based on highway payment system, could be implemented to allow customers exit without previous manual ticket payment. Security should be evaluated and some measure to avoid thefts may be implemented.


Vouchers or passes could be implemented to increase customers loyalty