Requirements

Functional Requirements:

• Users can see available shows.
• Users can view a seating map to pick seats.

Non-Functional Requirements:

List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

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

GET /v1/events

-> Returns paginated list of shows.

GET /v1/events/{id}/seats

-> Returns seat map with availability.

POST /v1/bookings/reserve

Body: { event_id, seat_ids[], user_id }

-> 200 OK (Starts TTL hold)

POST /v1/bookings/confirm

Body: { reservation_id, payment_info }

-> 201 Created (Finalizes purchase)

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.

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.

1. Booking Service (Critical)

Uses Redis Distributed Locks with a TTL of 10 minutes per seat hold.

If payment completes → write to DB.

If TTL expires → seat is auto-released.

2. Event/Seat Service

Heavily cached in Redis.

Seat availability is a bitmap structure for fast read performance.

Invalidate cache on every booking confirmation.