System requirements

Functional:

1.Type of vehicle to be parked whether it will be a 2 wheeler or a 4 wheeler.

2.Calulate the space estimation

3.Check in and checkout time

4.Size of vehicles.

5.Booking the parking space.

6.Creating a alert if the parking space is booked and also for check out time

Non-Functional:

1.A breach limit if he fails to checkout at the given time which will be efficient for others as well

2.A waiting list number if the parking is booked already

Capacity estimation

Suppose a user makes a call for parking spot

We will assume that frequency will be frequent 1000 bookings in an hour

That is 1000*24 =24000 bookings in a day

Booking space will have the details of user name and a unique id

12KB Approx space for detail

24000 *12 =288000 KB Space of data

288 MB for day

288*360 =97 GB for year

API design

Define what APIs are expected from the system...

getuser(id,user_name_checkin_checkout)

getisparkingavialable(no_of_spots,id_avaialble)

checkinuser(id,user_name,timestap)

checkoutuser(id,user_name,timestamp)

Database design

The primary model requires mapping of user with the parking spot he has occupied and availaiability for this Consistency and Availability are key .We can least consider Partial Intolerence for now.

We might require SQL database desing and Redis for cache loading .Also we need to handle concurrency as well there are chances 2 user booked a same parking spot.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Request flows

slots_available(slots)

An intial number would be shows to user to check if he can book or will be in waitinglist

book(user,id,slotid,timestamp,checkinttime,checkoutime)

A booking will be made with user detail ,a unique id ,slot id which will show the parking area user book and timestamp when booking is made

his checkin and checkouttime

cancel_book(user,id,timestamp)

If user wish to cancel booking we might require his id and user as welll .We will first check if it exist or not with user exist in database and as well as the id

booking_status()

user will recieve a 201 status for success booking or a failure message if booking was unsuccesgull

Detailed component design

For a parking lot system, let's focus on three key components from the flowchart:

2. Load Balancer

The load balancer distributes incoming traffic from the client to the various backend servers. This ensures high availability, fault tolerance, and optimal resource utilization, especially in large systems with many users.

• Responsibilities:
  • Distributes incoming client requests to multiple servers to balance the load.
  • Provides redundancy in case a server goes down (health checks and failover).
  • Enhances performance by routing requests to the least busy server or the one closest to the client.
• Technologies:
  • Software load balancers: NGINX, HAProxy, or cloud-based options like AWS Elastic Load Balancer (ELB) or Google Cloud Load Balancer.
  • Algorithms: Implements various load balancing algorithms like round-robin, least connections, or IP hashing to manage incoming requests efficiently.
• Challenges:
  • Handling spikes in traffic, especially during peak hours or events.
  • Ensuring minimal latency when distributing requests across servers.

3. Queue (Message Queue)

The queue component is responsible for managing asynchronous tasks, such as handling bookings, processing payments, and ensuring that system updates are processed efficiently.

• Responsibilities:
  • Manages asynchronous tasks like reservations, payments, and notifications, preventing the system from being overwhelmed during peak loads.
  • Decouples different parts of the system (e.g., parking reservation and payment processing) to ensure they operate smoothly without delays.
  • Handles retry mechanisms for tasks like failed payment transactions or reservation conflicts.
• Technologies:
  • Message Queues: RabbitMQ, Apache Kafka, or Amazon SQS.
  • Task management: Workers and consumers fetch tasks from the queue for processing, enabling scalable asynchronous processing.
• Scenarios:
  • When a user tries to book a parking spot, the booking request is placed in a queue to ensure no two users reserve the same spot simultaneously.
  • Payment processing or sending notifications to the user after a successful booking is also handled by the queue, ensuring smooth flow even under heavy loads.
• Benefits:
  • Improves system scalability by allowing tasks to be processed asynchronously.
  • Increases reliability, as tasks in the queue can be retried in case of temporary failures.

Trade offs/Tech choices

An IoT Sensor can be used which can collect a real time data and can also monitor parking as well

This real time data can helps in estimation for the amount and types of vehicle occupying during days ,and can prove to improve efficiency as well

Failure scenarios/bottlenecks

Scaling of data needs to consider

Proper handling of concurrency has not been done yet

A failed scenario for other user if suppose 2 user books the same spot we must notify a failed transaction as well.

Future improvements

Improvement to have a partial database for those table where sql is not required like slot availiabilty and all.

Pessimistic and optimistic locking for handling failed concurrency scenario