Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• Users can pay and be assigned a entry QR code and "latest arrival time."
• When paying, users must choose an "anticipated stay" duration. An estimated cost UI must be shown, encouraging them to be honest.
• When paying, users must give make/model/color/year details about their car.
• Users who do not show up are not charged.
• When paid users arrive on time and are apparently at the gate, they can be assigned a spot and the gate opens for them.
• Handicap users are assigned to accessible spots.
• Large vehicles are assigned to "large vehicle spots," if the parking lot is at 50% capacity during arrival, or if the parking lot is expected to hit 75% capacity within their anticipated stay. Otherwise, the following "convenience" ranking is used instead.
• When assigned a space, users should receive the most convenient space available, based on a convenience ranking each space has.
• Users with a total stay duration over 2 hours will receive a notification 20 mins before their expiration.
• Users who overstay will receive a notification, informing how overstay charges are calculated.
• Users can exit the lot and their parking space becomes available for others and their payment total is determined and debited. The total must take into account overstay charges.
• Users who exit the lot via tow or other forceful removal are still detected as exiting.
• Once a user scans a QR code for entry, it can be re-used infinitely for another 3 minutes, and then expires.
• A "I need a new QR code" option is available for users who already used QR code to enter. Clicking it requests the users to take a picture of their car. If the picture apparently matches the make/model/year/color described when checking in, and is apparently NOT in the parking lot, and the datetime of the image is AFTER QR scan, a fresh QR code will be assigned to their purchase record, which they can user to retry entering.
• The QR can be used to exit an unlimited number of times until it expires 24 hours after use for exiting.
• When the system is unavailable, the local gating system has an emergency code which can be shared over text/telephone to users, which can be used open the gate when the local system has no access to the remote system.
• The emergency code changes daily via local compute at the gate device, but is deterministic, so that customer support staff know the emergency code each day without needing connection to the gate.

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• The system can support tens of thousands of parking lots globally.
• Users experience sub second latency in all interactions with the system.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

Individual parking lots at peak traffic are known to produce 0.1 QPS "check out traffic", 0.01 QPS "check in traffic", and 0.01 QPS "purchase traffic".

100,000 parkings lots experiencing peak traffic simultaneously is highly unlikely but would yield a worst-case scenario load of 1k QPS check in traffic, 1k QPS "purchase" traffic, and 10k check out traffic.

Due to the nature of regional parking lots and timezones, we expect a more realistic ceiling of 1/4 that. These are the ceilings the business is comfortable designing for within the next 5 years of business:

250 QPS Payments

250 QPS Check In

2,500 QPS Check Out

QR Code requests scale with check ins and check outs; roughly 2750 QPS total.

Because this traffic is split across three regions, but not necessarily divided across those three regions evenly, projections calculated in a separate document estimate that the hottest region will still hit...

150 QPS Payments

150 QPS Check In

1,500 QPS Check Out

1,650 QPS QR Codes

These are what we design for ultimately.

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

POST /Order

Reply is 202 with URL to check status (GET /Order/{id})

GET /Order/{id}

POST /LotActivity

Reply contains {activity:entry}

Logic

• Exit?
  • READ QR Code, filter out expired.
  • Verify QR code is for an order at this garage.
  • Write exit record
  • Return
• Entry?
  • READ QR Code and Order, filter out expired.
  • Verify QR code is for an order at this garage.
  • Verify Order status
  • write LotActivity
  • Return allow/reject response

GET /QR/{orderId}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

To provide the fastest latency, the backend services will be deployed in three different regions. Traffic will be Geo DNS to the nearest deployment. The benefit is latency. While this divides traffic into thirds, it is not expected to be distributed evenly across those three. See capacity estimation.

Order service, lot activity service, and QR service are each and individual AWS lambda deployments.

Atomicity of payments + QRcode + DDB data writes is managed via saga design pattern and our reliance on the Payment Service's "at least once" event API, such that our saga will be called repeatedly by our PaymentService until we ack receipt of the event. Our handler for that event will be idempotent.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Order

• Order ID (Indexed)
• User ID (indexed)
• QR Code ID (Indexed)
• Vehicle year/make/model/color
• Estimated departure time
• Quoted price
• Payment Authorized
• Audit fields

QR Code

• QR Code ID (indexed)
• Order ID (Indexed)
• TTL
• Audit fields

User

• ID (Indexed)
• Names, etc
• Audit fields

LotActivity

• User ID (Indexed)
• Lot Id (Indexed)
• Activity (Entry/Exit)
• Audit Fields

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

Order service, lot, activity, service, and QR service, are each served by their own individual AWS Lambda.

QR service has smallest workload per request (fetch code and return it). Anticipated latency ~50ms, little's law yields ~80 concurrent Lambdas at peak.

LotActivityService needs to read, think for single digit ms, then write. Anticipated ~100ms latency. little's law yields ~160 concurrent Lambdas at peak.

EntryListener is a DynamoDB data change listener ("Data Capture" design pattern) and will notice when an entry happens for the first time and writes a TTL onto the QRCode so that it disappears from database, per requirements. EntryListener is expected to run in batches and not expected to run concurrently (only 1). This data capture design pattern also implements a outbox pattern, where we ensure the TTL gets written whenever entry data changes, and we don't depend on the app logic owning the LotActivity mutation to properly handle the QRCode TTL.

Order Service handling POST needs to create a step functions "saga" and return a 202. Anticipated latency ~50ms, little's law yields ~80 concurrent Lambdas at peak.

Order Service handling GET needs to fetch and return an order status and return a 200. Anticipated latency ~50ms, little's law yields ~80 concurrent Lambdas at peak.

All these service endpoint Lambdas will contain only code for their endpoint, and not the entire service and GO will be used as the programming language, with minimal dependencies, so cold starts are expected to be minimal. Parking lots have gradual traffics growth characteristics and we don't expect cold start storms to blow out concurrency.

The StepFunctions Payment Saga will run lambdas in concurrency as well, to generate QR Code, get payment, and update order status along the way. It's expected to yield roughly ~160 concurrent Lambdas at peak also.

Total concurrent Lambdas at this point is ~560, and that's at the worst case traffic peak ceiling business doesn't expect to hit. AWS limit is 1000.