System requirements

Functional:

1. The parking system should allow users to book a parking lot, check-in and check-out, make payment for service, if there is no current availability notify them once slots are available.
2. Users will login with their phone number or email id which will unique key at our system. They can book a parking slot. There will also be an option to book slot in advanced for a week or months if the customer has a regular visits.
3. We will keep user / customer information and one entity will be there which will be for the parking slots. When a customer requests we will check if our system has any available slot, if yes then will create an entry for user and slot id.
4. Vehicles should have papers and driving license.
5. If user is not present, we throw an error asking to register himself / herself. If no slots are available we will show a message "No slot available". If there is system failure then we will show "Internal Server Error".

Non-Functional:

1. We should allow users to check availability and book slot in real time taking response time not more than a second.
2. We will have load balancers which will equally distribute requests and will route the requests to only healthy clusters.
3. Proper alerting system to monitor health checks and immediate actions if certain threshold is breached.
4. Proper authentication of users for login and signup.
5. We should ensure that there is proper interaction within our system and no concurrent operations going i.e if two users tried to book a the same slot same time, booking should not happen for both the users.

Capacity estimation

We will create a system to handle 100k+ rps.

API design

1. Sign Up / Login Page : API to register user if not present else allowing signing in.
2. Making a booking : Allowing a user to book a slot at a particular time.
3. Checking availability: Allowing users to see available slots so that they can plan.
4. API to show pricing for book a reservation: Cost of booking a slot can be dynamic like cost can be more during peak hours and little less in odd hours. If you are a regular customer, we show offers. We will keep an intelligent system at our end.

Database design

UserProfile Entity

CREATE TABLE user_profile (

'user_id' string primary key,

'email_id' string,

'phone_number' string,

'active' boolean,

'address' varchar(255),

)

CREATE TABLE slot (

'slot_id' string primary key,

'available' string,

'location_id' string

)

CREATE TABLE user_slot_mapping (

'user_id' string primary key,

'slot_id' string primary key,

'active' string,

'valid_till' string

)

High-level design

Backend:

Load balancer to route request to healthy instances constantly, cache to reduce load on database,

rabbit MQ for asynchronous request handling, Push notification system for notifying agents.

Clients make a request, request is routed from APP to API gateway which then sends it it load balancer from where request is routed to servers.

Request flows

Client ->APP -> API Gateway -> Load balancer -> Server -> Cache -> Database.

Detailed component design

For handling multiple request we can do scaling like adding more servers, increasing RAM size.

Tech Stacks: Java, Dropwizard, Maria DB, Aerospike, Caffeine, Singleton, Indexing.

Trade offs/Tech choices

Using a microservices architecture for scalability and independent deployments, instead of a architecture.

 Java for its performance and robust libraries.

Use caching (e.g., Redis or Memcached) to improve performance by reducing database load.

 Use of load balancers to distribute traffic evenly across servers.  Load balancing increases fault tolerance and server utilization but adds complexity to network setup.

1. Real-time Processing:
   • Using message queues, like RabbitMQ or Kafka, for processing asynchronous tasks.
   • Trade-offs: Message queues improve response times and decouple services but add layers to the architecture.
3. Real-time Processing:
   • Using message queues, like RabbitMQ or Kafka, for processing asynchronous tasks.
   • Trade-offs: Message queues improve response times and decouple services but add layers to the architecture.

Failure scenarios/bottlenecks

1. Description: This can occur due to hardware failures, software bugs, or external service outages.

Prevention:

1. 1. Implement redundant servers and services to ensure the system can handle failures gracefully.
   2. Use monitoring tools to detect issues early, coupled with alerting systems for quick response.
   3. Schedule regular patching, updates, and system health checks.

2. Description: The system could struggle under heavy traffic, leading to slow performance or downtime.

• Prevention:
  • Load Balancing: Use load balancers to distribute traffic among multiple servers, preventing any one server from becoming a bottleneck.

Backup and Data Recovery:

• Description: Loss of data due to system crashes, database corruption, or cyber-attacks.
• Strategies:
  • Regular Backups: Schedule frequent backups of databases and critical system state to prevent data loss.
• Geographic Redundancy: Store backups in multiple locations or data centers to safeguard against regional failures.
• Automated Recovery: Implement automated recovery procedures to restore service quickly in case of failure.

Future improvements

• Load Balancer: Distributes incoming traffic across multiple servers, enhancing load management.
• Auto-Scaling Group: Automatically adjusts the number of active servers based on traffic conditions.
• Cache (Redis): Reduces database load and improves response times by caching frequent queries.
• Backup Service: Regularly creates backups of crucial data, stored in geographically redundant locations.
• Monitoring & Alerts: Actively monitors server health and performance metrics, triggering alerts on anomalies.