System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. User Registration and Authentication - create an account, login, manage parking experiences
2. Real-Time availability - Users to have ability to see real-time data on available parking spots, including the type of vehicle each can accommodate.
3. Parking reservation - Ability to reserve with expected entry and exit times.
4. Vehicle entry and exit management - implement electronic barriers that control access based on reservations or real-time availability
5. payment processing - secure payment for users to pay for their parking either in advance or upon exiting
6. Parking spot allocation - allocate parking spots based on user requirements (handicapped, electric) and optimize spots.
7. Notifications and alerts - users with notifications for their reservations, reminders before their time expires, alerts for any changes in availability.
8. reporting and analytics - collect data and usage patterns, peak times, revenue generation, for operational insights.
9. Security Features - surveillance, emergency services protocols
10. Admin Dashboard - interface for administrators to manage parking zones, availability, monitor overall operations.

Non-Functional:

List non-functional requirements for the system...

1. Scalability - system be able to handle growth without degradation in performance (users and parking spots)
2. Performance - Allow users to find available parking spots, reserve them, complete payment processes within a reason time frame. Ideally under 2 seconds for all transactions.
3. Reliability - Ensure 99.9 uptime, even during peak usage times
4. Security - Robust security measures to protect user data, encryption for payment and user creds.

Capacity estimation

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

For size we are going to move with a medium parking lot with 300 spots available.

The parking spots will be 200 Sq ft to keep simple. there will be 300 spots

200sqft x 300 = 60000 sq ft total area

Summary

• 6 peak hours a day (7-9am, 12-2pm, 5-7pm)
• 18 non peak hours - 50% usage
• 2 hr average time in parking lot

Average time in parking garage

• 2 Hrs
• 6 hours /2 average time =3 cars in 1 parking spot during peak hours * 300 = 900 cars during peak hours
• System needs to handle a minimal of 900 cars per day.
• Non peak usage at 50%
• 300 spots * 50% = 150 spots
• Non Peak = 18 hours and half of peak (150 cars - half of peak)
• Non peak = 18 hours / 2 hours = 9 cars * 150 spots 1350 cars during non peak hours
• Total = 1350 nonpeak + 900 peak = 2250 cars daily in parking garage

API usage

• Average of three visits daily to check availability, reservations, check-in-checkout
• 2250 total cars based on availability and turn over
• 2250 cars * 3 visits = 6750 minimal visits a day
• 6750 visits * 70% = 4725 visits during peak hours
• 4725 api calls at hour / 6 hrs = 788 api calls and hour for 6 hours
• 788 api calls hrly / 60 minutes = 13 API calls a minute during peaks hour
• 6750 total - 4725 peak hour API calls = 2025 non peak hour api calls
• Triple peak per minute = 13 x 3 = 39 RPS API calls per minute
• Triple peak per hour = 39 x 60 2340 RPS API calls per hour

Transaction history should have a retention of 3 - 5 years for tax purposes.

API design

Define what APIs are expected from the system...

API will need to at minimal handle these requests

1. Availability - checked without login
2. Registration / create account
3. Reservations - with login
4. check-in / checkout
5. Login

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

For Database Design I would pick two PostgreSQL databases

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

Two L7 Active/active Load balancers

Redundant Gateway API

two general purpose Servers cloud servers EC2 AWS

Two PostgreSQL Databases

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

Flow:

Client sends request to public DNS address

This lands at Load balancer layer

Load balancer sends to Gateway API

Gateway API sends to backend servers that handle all the different types of requests

Backend servers will query the databases for information

Databases return information to the backend servers

backend servers return traffic Gateway API

Gateway API returns traffic to Load Balancers

Load Balancer returns to client

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Frontend

• Authentication
• Realtime updates
• Reservation system
• checkin / checkout
• alerts and notifications

I would use React and react native for mobile to handle the UI, user interactions and communication with the backend API calls.

1. App component - manages everything between views. Use react router to manage page navigation
2. Login component - User enters user and password, form validation to ensure that all fields are correctly populated, API call sends an HTTP POST request to the backend API to authenticate the user.
3. Parking availability - display real-availability, fetches parking spot info from the backend via HTTP GET request and displays. updates using websockets
4. reservation component- allows users to view existing reservations and make new ones. Selecting a parking spot and time, sends a POST request to the backend to make reservation.
5. checkin/checkout component - allows user to mark their arrival and departure. Sends requests to backend to update parking spot status in real time

Next Load Balancer will be AWS Load Balancer ELB

1. TLS terminations to encrypt and decrypt traffic. Health checks to ensure healthy instances server traffic. Load Balancing using using sticky or session persistence. The ELB will be set to autoscale for availability

API Gateway will also be in the load balancer layer Amazon API Gateway

1. When frontend sends a login or reservation request the API gateway routes the traffic to one of the healthy backend servers. This will autoscale with the ELBs

Backend servers will be AWS cloud ECS servers.

1. These servers will use Python (Flask). Core backend functions will be
   1. Login API which verifies creds and creates session token. Going deeper here we will validate creds against user database (hashed passwords stored using bcrypt). Session generation token when authenticated successfully. response is sent back to frontend and future API requests include this token in the header for authorization. All secured API endpoints check for a valid session token the authorization header, invalid or expired token trigger a 401 unauthorized response.
   2. Parking availability API - returns number of parking spots
   3. Reservation API - handles reservations, prevents double booking via ACID transactions
   4. Checkin/checkout API - updates parking spot status when user arrives, departs.

Databases will be Amazon RDS for PostgreSQL

1. function is to store all critical data: user data, parking spot data, reservation details, checkin/checkout records.
2. DB interactions
   1. Login - queries the user table to validate credentials during login
   2. Reservation - updates availability in an ACID-compliant transaction to prevent overbooking.
   3. analytics - stores data for reporting and business analytics

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

ELB with API Gateway - adds minor additional latency however it would add more latency if you separate these add an additional routing hop. also combining this to the ELB adds resource use. This may add cost eventually as we scale.

ELB with API Gateway - complexity in configuration, more development time.

AWS ECS with Python Flask - cold start delay for scaling containers.

AWS ECS with Python Flask -Flask’s synchronous nature may limit concurrency

Amazon RDS (PostgreSQL) - Scalability limited for high-write workloads.

Amazon RDS (PostgreSQL) - Performance overhead with ACID

Amazon RDS (PostgreSQL) -Costs rise with data size and replicas

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

API Gateway latency or throttling

1. API will enforce quotas and throttling limits. exceeding will rate limit leading to delayed or failed API responses. This means timeouts , inability to check availability, reservations and degraded user experience.

Load Balancer failure - outage in an AWS region - could prevent traffic from reaching ECS instances.

AWS ECS failures - Container crash, out of memory errors.

ECS Service Scaling delay - ECS autoscaling may take time to spin up additional containers, leading to overhead on existing containers.

No caching layer - This causes heavier load on the databases - increased need to resources that we could offload to a cache.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?

API Gateway latency or throttling

1. Monitor API metrics and increase quotes or Implement exponential backoff retry strategies on the client side

Load Balancer failure - Use multi region LB or GLB for autofailovers to another region.

AWS ECS failures - use ECS auto-restart policies, monitor ECS task health. Use AWS

Cloudwatch alarms to replace failed tasks.

ECS Service Scaling delay - proactive scaling based on PEAK hours or use EC2 instances

Add caching layer - Redis cache