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.

10. Detailed component design

I’d deep dive into these 3:

Inventory / Spot Allocation Service
Gate Control Service
Reservation + Payment orchestration

10.1 Inventory / Spot Allocation Service

This is the hardest core logic.

Responsibilities

maintain spot inventory per lot/time window
prevent double-booking
support spot type constraints
optionally assign exact spot up front or at entry time

Design choice: exact spot vs spot class reservation

There are two models:

Option A: Reserve exact spot at booking time

Pros:

simple user experience
deterministic

Cons:

lower utilization
more fragmentation
difficult if users leave early or no-show

Option B: Reserve a spot class/capacity bucket, assign exact spot at entry

Example: reserve “SUV-compatible on floor B2”, assign actual spot when user arrives.

Pros:

better utilization
easier rebalancing
easier handling of no-shows and early exits

Cons:

more complex gate-time logic
slightly less user certainty

Best practical choice:

Use spot class reservation, then assign exact spot at check-in or shortly before arrival.

For premium/VIP/accessibility cases, exact spot reservation can still be supported.

Inventory representation

At low scale, you can simply query DB rows for overlapping reservations.

At higher scale, better to maintain:

spot metadata in SQL
availability counters / interval indexes in Redis or specialized allocation layer

Core allocation rule

A spot can be assigned only if:

vehicle type fits
spot type fits
no overlapping confirmed reservation or active session
spot not under maintenance

Overlap condition

Two reservations overlap if:

new.start < existing.end AND new.end > existing.start

Preventing double booking

This is crucial.

Possible approaches:

Approach 1: DB transaction + row locking

lock candidate spot rows using SELECT ... FOR UPDATE
verify no overlap
insert reservation
commit

Pros:

strong correctness
simple at moderate scale

Cons:

can become bottleneck for huge scale

Approach 2: Redis distributed lock + DB transaction

acquire temporary lock on candidate inventory bucket
perform DB transaction
release lock

Pros:

lower contention at app layer
faster for hot lots

Cons:

more complexity
must handle lock expiry correctly

Approach 3: Pre-aggregated capacity buckets

Instead of exact spot selection during booking:

maintain capacity by (lot, spotType, timeSlot)
decrement counters on booking
assign exact spot later

Pros:

scales much better
faster availability queries

Cons:

less precise
needs reconciliation with real spot-level state

Interview recommendation

Start with:

SQL transactional allocation
Then mention evolution:
move to bucketed inventory with Redis caching
exact spot assigned at check-in

That is a strong, pragmatic answer.

Data structures

SQL tables for canonical reservations/sessions/spots
Redis:
- hot availability counts
- temporary booking holds
- gate lookup cache by plate -> reservation/session
optional interval tree / time-slot buckets for fast overlap computation if scale grows

Scaling strategy

Shard primarily by:

lotId

Why?

reservations and gates are mostly lot-local
avoids cross-lot contention

For large deployments:

one inventory partition per lot/region
cache popular lots heavily

10.2 Gate Control Service

This is operationally critical.

Responsibilities

receive entry/exit events from hardware
identify vehicle
authorize or deny access
open gate
create check-in / check-out events
operate under intermittent connectivity

Inputs

LPR camera plate read
QR code
kiosk/manual operator override

Entry logic

receive plate
find matching confirmed reservation for current time window
validate grace period
if exact spot not assigned, request spot from allocation engine
create parking session
send open command to gate

Exit logic

find active session by plate
calculate final charge/refund/penalty
verify payment state or settle delta
close session
open exit gate

Latency and resilience

This service must be very fast.

So I would keep:

local cache / Redis cache for plate -> active reservation/session
idempotent gate event processing
offline fallback rules

Offline fallback

If central backend is temporarily unavailable:

gate controller can use a short-lived local cache of recently synced valid reservations
operator override can be used
events are queued and reconciled later

This is a strong real-world point.

Fraud / error cases

misread plate
user changes vehicle
fake QR
car enters without reservation
duplicate entry events

Solutions:

support QR/manual confirmation fallback
idempotency key on gate events
camera confidence threshold
operator console for exception handling

Scale

Gate traffic is not internet-scale, but spikes can happen at event venues.

Example:

50 lots
20 gates each
1 event causes 2000 cars in a short window

Still manageable with:

stateless Gate Control Service
Redis hot cache
lot-based partitioning

10.3 Reservation + Payment orchestration

This is where distributed workflow correctness matters.

Why it is tricky

Reservation and payment involve multiple systems:

our backend
inventory
payment provider

We need to avoid:

paid but no reservation
reservation created but payment failed
double callback processing

Best approach: Saga / state machine

Flow:

user requests booking
create reservation in PAYMENT_PENDING
create temporary hold on inventory
initiate payment
payment callback arrives
confirm reservation and convert hold to confirmed booking
if payment fails or times out, release hold

This is effectively a mini saga.

Why not one global distributed transaction?

Because PSP is external and distributed 2PC is impractical.

Idempotency

Need it for:

create reservation
payment callback
gate events
refunds

For example, payment callback may arrive twice.

So we store:

externalPaymentRef
processed status
idempotency key

Early departure

Business rule options:

Option 1: no refund

simple, good for operators

Option 2: prorated refund

better UX, more complex

Option 3: credit for future use

great compromise

I would say:

support configurable policy per lot/operator

Flow:

exit event closes session
compute actual usage
compare against reservation payment
issue refund/credit if policy allows
release remaining reserved capacity

No-show

Need a configurable grace period, e.g. 15 minutes.

Flow:

scheduler scans reservations whose start time + grace < now
if not checked in:
- mark NO_SHOW
- free inventory
- apply penalty/refund policy
- notify user

This can be implemented using:

delayed jobs in queue
periodic sweeper job

I prefer delayed jobs because they are more targeted, but a periodic sweeper is simpler as backup.

11. Database design

Transactional SQL DB

Use PostgreSQL/MySQL for source of truth.

Why SQL?

reservations/payments/sessions are transactional
need consistency
rich querying for overlaps/auditing/reporting

Example tables

users
vehicles
parking_lots
parking_spots
reservations
sessions
payments
gate_events
no_show_events

Important indexes

reservations (lot_id, start_time, end_time, status)
reservations (vehicle_id, start_time)
vehicles (plate)
sessions (plate, status)
spots (lot_id, type, status)

Redis

Use for:

hot availability cache
temporary inventory holds
plate-to-reservation lookup cache
gate-side fast authorization path

Event bus

Kafka / RabbitMQ / SQS-like queue for:

payment callbacks
no-show jobs
notifications
analytics/audit streams

12. Capacity estimation

For interview purposes, keep it simple.

Example:

1,000 parking lots
each lot has 500 spots
average 5 reservation/session events per spot per day

That gives:

500,000 spots total
2.5M reservation/session events/day

This is not massive for a modern SQL + cache + queue architecture.

Peak traffic is the real concern:

morning commute
event venue opening/closing
holiday traffic

So design for:

burst handling
cached reads
async side effects
low-latency gate path

Submissions

Displaying Solutions with Scores Ranging from 1 to 10