Detailed Component Design

I would deep dive into three important components:

1. Seat Reservation Service

2. Booking and Payment Service

3. Search and Caching Layer

==================================================

1. SEAT RESERVATION SERVICE

==================================================

The Seat Reservation Service is the most critical component because it must prevent double booking.

Each seat for a particular show has one of three states:

AVAILABLE -> HELD -> BOOKED

If the user does not complete payment within the hold period:

HELD -> AVAILABLE

For example:

AVAILABLE

|

| User selects seat

v

HELD

|

+---- Payment succeeds ----> BOOKED

|

+---- Hold expires --------> AVAILABLE

When a user selects seats A7 and A8, the Reservation Service performs an atomic transaction.

Conceptually:

BEGIN TRANSACTION

SELECT *

FROM show_seat

WHERE show_id = ?

AND seat_id IN ('A7', 'A8')

FOR UPDATE

The service checks that all seats are AVAILABLE.

If they are available, it updates:

status = HELD

hold_id = generated_hold_id

hold_expires_at = current_time + 5 minutes

COMMIT

Because the rows are locked inside the transaction, another transaction trying to reserve the same seats cannot successfully reserve them simultaneously.

If two users attempt to reserve seat A7 at exactly the same time, only one request should succeed.

Pessimistic Locking:

We can use:

SELECT ... FOR UPDATE

Advantages:

- Easy to reason about

- Strong consistency

- Prevents double booking

Disadvantages:

- Lock contention

- Reduced concurrency for very popular shows

Optimistic Locking:

Another option is adding a version field to ShowSeat.

Example:

seat_id = A7

status = AVAILABLE

version = 5

Update:

UPDATE show_seat

SET status = 'HELD',

version = 6

WHERE show_id = ?

AND seat_id = ?

AND status = 'AVAILABLE'

AND version = 5

If rows affected = 1:

Reservation succeeded.

If rows affected = 0:

Another user modified/reserved the seat first.

Optimistic locking can provide better throughput but requires retry/error handling.

Hold Expiration:

Seat holds should last approximately 5 minutes.

A background worker periodically finds expired holds and changes:

HELD -> AVAILABLE

Another implementation option is maintaining hold expiration entries in Redis using TTLs while keeping SQL as the source of truth.

==================================================

2. BOOKING AND PAYMENT SERVICE

==================================================

The Booking Service converts a valid seat hold into a confirmed booking.

Typical flow:

1. User reserves seats.

2. Seats become HELD.

3. Booking Service creates a PENDING booking.

4. Payment Service calls the external payment provider.

5. If payment succeeds:

- Booking becomes CONFIRMED.

- Seats become BOOKED.

6. If payment fails:

- Booking becomes FAILED.

- Seats are released back to AVAILABLE.

7. A booking event is published to the message queue.

8. Notification workers send the ticket/confirmation asynchronously.

Booking state machine:

PENDING -> CONFIRMED

PENDING -> FAILED

Payment state:

PENDING -> SUCCESS

PENDING -> FAILED

Idempotency:

Payment and booking APIs should support idempotency.

For example, the client sends:

Idempotency-Key: booking-user123-hold456

If the user's network times out and the application retries the request, the server checks whether the same idempotency key was already processed.

If it was processed successfully, the server returns the existing booking instead of charging the customer again.

This prevents duplicate bookings and duplicate payments.

Distributed Transaction Problem:

The payment provider is an external system, therefore we cannot rely on one traditional database transaction covering both our database and the payment provider.

Instead, the booking process should use a state machine / saga-like workflow.

For example:

Seat HELD

->

Booking PENDING

->

Payment Request

->

Payment SUCCESS

->

Booking CONFIRMED

->

Seat BOOKED

If payment fails:

Payment FAILED

->

Booking FAILED

->

Seat AVAILABLE

==================================================

3. SEARCH AND CACHING

==================================================

Most application traffic will be read traffic rather than booking traffic.

Typical high-volume requests include:

- Search movies

- Find theaters

- View showtimes

- View movie information

- View seat maps

These operations can tolerate eventual consistency.

The Search Service can use Elasticsearch/OpenSearch for fast movie and theater searches.

Redis can cache frequently accessed data such as:

- Popular movies

- Theater information

- Showtime listings

- Seat availability snapshots

Example cache keys:

movie:movie123

theater:theater456

show:show789

show:show789:seats

Request flow:

Client

->

API Gateway

->

Search/Showtime Service

->

Redis

If cache hit:

Return result immediately.

If cache miss:

Read from database/search index

->

Return result

->

Populate Redis

Redis reduces load on the primary databases and significantly improves read latency.

However, Redis should not be considered the authoritative source for confirmed seat bookings.

The SQL Seat Inventory database remains the source of truth.

==================================================

SCALING

==================================================

Application services are stateless and can be horizontally scaled behind a load balancer.

For example:

Reservation Service

Instance 1

Instance 2

Instance 3

...

Instance N

Database Scaling:

1. Add read replicas for read-heavy operations.

2. Use indexes on commonly queried fields.

3. Partition/shard seat inventory by show_id.

4. Cache frequently accessed metadata in Redis.

5. Use OpenSearch/Elasticsearch for search workloads.

A natural shard key for seat inventory is:

show_id

because most reservation requests operate on seats belonging to one specific show.

Example:

hash(show_id) % number_of_shards

==================================================

ASYNC PROCESSING

==================================================

Operations that do not need to block the user request should be processed asynchronously.

After a successful booking, the Booking Service publishes an event to Kafka, RabbitMQ, SQS, or another message queue.

Consumers can independently process:

- Email notification

- SMS notification

- Push notification

- Analytics

- Audit logging

Example:

Booking Service

|

v

Message Queue

/ \

Notification Analytics

Worker Worker

This reduces booking latency and prevents notification failures from affecting the main booking transaction.

==================================================

KEY TRADEOFFS

==================================================

1. SQL vs NoSQL

I prefer SQL for seat inventory and bookings because these operations require ACID transactions and strong consistency.

NoSQL or search databases may still be used for read-heavy or search workloads.

2. Strong vs Eventual Consistency

Strong consistency:

- Seat reservation

- Booking

- Payment

Eventual consistency:

- Movie metadata

- Search

- Theater information

- Analytics

3. Consistency vs Availability

For movie browsing:

Availability > Strong Consistency

For seat booking:

Consistency > Availability

It is better to temporarily reject a booking request than accidentally sell the same seat twice.

4. Redis vs Database

Redis improves latency and reduces database load.

However:

Redis = Cache / Optimization

SQL = Source of Truth

==================================================

MAIN BOTTLENECKS

==================================================

1. Popular movie releases creating sudden traffic spikes.

Mitigation:

- Horizontal scaling

- Rate limiting

- CDN

- Redis

- Waiting-room/queue mechanism if necessary

2. High contention for the same seats.

Mitigation:

- Row-level locking

- Optimistic concurrency control

- Atomic conditional updates

3. Database overload.

Mitigation:

- Caching

- Read replicas

- Database indexes

- Sharding/partitioning

4. Payment provider failures.

Mitigation:

- Idempotency

- Retries with exponential backoff

- Payment webhooks

- State-machine based booking workflow

5. Notification failures.

Mitigation:

- Message queue

- Retry mechanism

- Dead-letter queue

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10