Loading...
Estimate the scale of the system you are going to design...
Storage estimates
9600 * 4 * 10 MB =980 GB/day
For 30 days 3000 GB / month
We will need couple API's
/api/v1/entry/vehicle_id - POST - This API is called whenever the vehicle enters the parking lot
/api/v1/exit/vehicle_id - POST - This API is called whenever the vehicle exits the parking lot
/api/v1/inventory/ - GET - This has the list of the available spaces in the parking lot, the response will also have spaces allocated for different types of vehicles spaces that are available , this will help in efficient managing of the vehicles. It has filter that we can use to get different types of vehicles
/api/v1/payment/vehicle_id - POST - This API is used to pay the fee for a vehicle
We will need two tables
vehicle - This has all the details like
vehicle_id: uuid
vehicle_reg: string
vehicle_type: string
vehicle_entry_time:
vehicle_exit time:
image_url
vehicle_image_data
vehicle_id:
image_url:
Parking:
available:
type:
So at a high lev
Usecase 1:
User is able to park the car
As soon as the car appraoches the gate the register vehicle service is called which captures the ehicle details like image and also the ANPR to get the number plate , once these details are captured , the register vehicle also directs the car to the right spot by telling which floor to proceed. As soon at the car enters we call the parking inventory service to update the parking inventory so that we can show the realtime availability to deduct one space from the inventory. We also make an entry to the payment DB that a vehicle has entered the facility and we store the vehicle_id in the DB
UseCase 2:
When the vehicle wants to wants to exit the parking facility again we call the register vehicle which again captures the image and when the user takes their card for payment we call the payment service for making the payment , once we complete the payment we update the payment DB and update the inventory to reflect the
Usecase 3:
We also can query vehicle details by using the get vehicle details service to capture the vehicle details including entry time , exit time and also image captures. We can also use this service to get the exact location of vehicle in the parking lot if we need to track it for security purposes.
We will talk about registe vehicle component that is doing a lot of heavy lifting.
This component is responsible for managing the lifecycle of a vehicle in the parking lot. So the first thing it does it register the vehicle , it does so first by using ANPR technolgy to capture the vehicle details , we will use a third party camera technology to get this data and next it also talks to parking inventory service to get the latest inventory and redirect the vehicle to the right parking spot, it also sends an event to payment service to register the vehicle.
Since the data volume is low both read and write we will use a SQL DB which has quick read times , we will use NoSQL DB as the data structure is more like key and value . where the key can be the vehicle id and we can store all the vehicle details in different columns.
For capturing and storing the images we will use Blob store like S3, this storage is optimized for storing images , also it helps with automatic deletion after 30 days.
For payment DB we will use SQL to ensure we have strong ACID like properties
For stroring parking lot inventory we can use key value store as we dont have much details to store. We need this to be real time as possible and the key value stores usually have relatively low latency .
Since there are lots of services calling we wil use a message queue like kafka which will help us manage the events and will keep the services decoupled.
All the databases are single point of failure .
All the services are single point of failures.
Messaging queue.
We will use replicas for each of the DB's to ensure we have the data backed up . We wil also back up the S3 data in multiple AZ's to ensure we have high availability . We will also ensure all our services are running on multiple isntances behind a load balancer. We will need to ensure we are using a distributed message queue as its very critical component for inter service comms via events.
We will also have auto delete for purging the vehicle details after 30 days.
We will also asyncronus replication between replicas to ensure we have consistent data between primary and secondary. This is to ensure we have proper failover to secondary from primary.
We will also have secondary load balancer
We will need to use robust monitoring and alerting policy to ensure we are monitoring the system health.