System requirements

Functional:

1. Vehicle Entry and Exit Management:
   • Automatic or manual entry/exit gates.
   • License plate recognition for automatic entry and exit.
   • Ability to handle different vehicle types (cars, motorcycles, etc.).
2. Real-time Parking Space Tracking:
   • Monitor and display available parking spots in real-time.
   • Notify users of spot availability via a mobile app or display boards.
3. Reservation System:
   • Allow users to reserve parking spaces in advance.
   • Provide confirmation and reminders for reservations.
4. Payment Processing:
   • Multiple payment options (credit card, mobile payment, etc.).
   • Ability to issue invoices or receipts for transactions.
5. User Authentication:
   • User accounts for tracking history, preferences, and payment methods.
   • Integration with social media or email for account creation/login.
6. Security Features:
   • Surveillance cameras for monitoring the parking lot.
   • Alerts for unauthorized access or tampering.
7. User Notifications:
   • Notifications for expiry of parking duration.
   • Updates on traffic within the parking lot (if it's getting full).
8. Maintenance and Management:
   • Ability to keep track of maintenance schedules for the parking lot and its equipment.
   • Analytics dashboard for parking lot performance metrics.
9. Feedback Mechanism:
   • Allow users to provide feedback on their parking experience.
   • Implement a rating system for the cleanliness and safety of the parking area.

Non-Functional:

1. Performance:
   • The system should handle up to 1000 transactions per minute during peak hours without significant delays.
   • Real-time updates regarding parking availability should render in under 2 seconds.
2. Scalability:
   • The architecture should support scaling to manage an increase in users or parking lot locations, handling up to 10,000 users simultaneously without performance degradation.
3. Availability:
   • The system should have an uptime of 99.9%, ensuring it's accessible to users nearly all year round.
   • Implement a failover mechanism to maintain service continuity during outages.
4. Security:
   • All user data and payment information should be encrypted both in transit and at rest, adhering to PCI-DSS standards.
   • User authentication must support two-factor authentication to enhance security.
5. Usability:
   • The mobile and web interfaces should follow best practices for user experience, making them intuitive and easy to navigate.
   • Provide onboarding tutorials or help sections for new users.
6. Maintainability:
   • The code should be modular and well-documented, allowing for easier updates and maintenance.
   • Regular maintenance windows should be scheduled and communicated to users.
7. Interoperability:
   • The system should be able to integrate with third-party services (e.g., payment processors, mapping services) to enhance functionality.
8. Compliance:
   • The system should comply with local regulations related to data protection (e.g., GDPR) and accessibility standards (e.g., ADA compliance).
9. Response Time:
   • The system should process user requests (like reservations or payments) within a specific timeframe, such as 3 seconds for most operations.
10. Monitoring and Logging:
    • Implement logging for all critical actions like entry/exit and payment processing.
    • The monitoring system should provide alerts for performance issues or security breaches.

Capacity estimation

Based on the performance requirement, 1000 transactions per minute. We can assume that 80% of the transaction is read. Since the write transaction only happens when user book the parking spot and give ratings. So we can say the read qps is 1000/60*80% = 15 qps. Write is 5 qps. And we can assume the peak time is 3 times which is 50 qps. That means in the beginning, 1 web server and 1 db server is sufficient. However, if we would like to support 10000 user simultaneously in the future, multiple servers or even cluster is required.

For storage, let's assume there are 10 character in the license plate, along with user name and other info, we can tell that the size of each record is about 300 bytes. Based on the assumption above, write qps is 5. So 300 * 5 * 60 * 60 *24 * 365 = 130MB per year.

API design

User Authentication

• User creation, POST user/register
• Get user info, GET user/get

Vehicle Entry and Exit Management:

• Fetch vehicle info for existing user by license plate number, GET vehicle/get
• For new vehicle, enter vehicle info and get a space based on vehicle type, POST /vehicle/park
• Payment, if the vehicle is not paid when approaching the exit,

Reservation system

• reserve a spot, POST spot/reserve
• cancel or change a reservation, PUT spot/cancel

Feedback Mechanism

• Write a feedback, POST feedback/create
• Edit a feedback, PUT feedback/edit

Maintenance and Management:

• Get maintenance schedule, GET maintenance/get
• Create maintenance schedule, POST maintenance/add
• edit maintenance schedule, POST maintenance/edit

Database design

User table

• user_id
• user_name
• user_type
• email
• password (encrypted)
• created_on

Payment method table

• payment_id
• user_id
• method
• card_number
• mobile_wallet_address
• created_on
• billing_address

Vehicle Table

• vehicle_id
• user_id
• vehicle_type
• license_plate_number
• created_on

Reservation Table

• reservation_id
• spot_id
• vehicle_id
• valid_from
• validation_to
• amount_paid
• created_on

Parking spot table

• spot_id
• type
• location
• equipment_id
• maintenance_schedule
• is_occupied
• is_accessible
• price
• created_on

Feedback Table

• id
• user_id
• content
• created_on

High-level design

flowchart TD

B["User"];

A["Admin"]

C{"Load Balancer"};

D{"API Gateway"}

E["User service"]

F["Vehicle Entry and Exit Management Service"]

G["Reservation service"]

H["Feedback service"]

I["Maintenance Service"]

J["Database"]

K["monitoring service"]

L["Payment service"]

M["Cache"]

B--> C

C --> D

D --> E

D --> F

D --> G

D --> H

E --> J

F --> J

G --> J

H --> J

I --> J

A --> I

A --> K

K --> J

G --> L

K --> B

Request flows

sequenceDiagram

participant A as User

participant B as Vehicle Entry and Exit Management Service

participant D as User service

participant E as Reservation service

participant F as Payment service

participant G as Feedback service

A->> +B: Try to enter

B->> +D: check user info

D->>-B: return user info

B ->>-A: return if the user can enter/Exit

A->> +E: make reservation

E->> +F: Payment

F->>-E: success

E->>A: reservation made

A->> G: create review

Detailed component design

• For the Real-time Parking Space Tracking, Security and user notification function, we can have them in the monitoring service. We will have a scheduled job to scan the parking spot table and reservation table and send notification to user if necessary. Also, it will update the cache with parking availability info and wait time.
• When user try to fetch the parking availability, it will try to fetch from the cache, so that it can ensure that the result can be returned to user within 2 seconds.
• If the vehicle type is not supported(too large or too small), we should return appropriate error message to the user.
• To ensure 99.9% uptime, we will have multiple service instances running and backup database ready. If master instance failed. traffic will fail over to slave instance.
• Process user payment and reservation asynchronously to minimize response time and notify user if there is a failure.

Trade offs/Tech choices

• Relational database is chosen here since the data we want to store is well structured and we have the need to query the data by relations. And it can handle the qps for the system
• Micro service architecture is used here so that each service can be deployed and scaled independently. Especially the Vehicle Entry and Exit Management Service, reservation service and payment service.
• Use cache (like Redis) to store parking availability info to ensure short response time.
• Eventual consistency is used here to ensure response time requirement.

Failure scenarios/bottlenecks

• Since we are using cache to store the parking availability info, there could be a race condition that the available spot may be already booked by another user or the spot is under maintenance.
• If user volume keeps increasing, single table may not be sufficient.

Future improvements

• We may need another service to ensure the data in cache and database are in sync and notify admin if there is a problem.
• Or we can create index for spot_id and is_occupied to reduce query time. May also need to use perform performance test to get an appropriate solution.
• Database sharding will be used.