0. Ticket Master

---

1️⃣ Requirements

Functional Requirements

Core features:

👉 “Users should be able to…”

• Search for events
• View event details
• Book tickets

Non-Functional Requirements (WHERE MOST PEOPLE FAIL ⚠️)

❌ Wrong: Scalability, availability, reliability

✅ Correct (context-specific):

1. Consistency vs Availability

• Booking → Strong Consistency
  • No double booking ❗
• Search/View → High Availability
  • Slight delay acceptable

2. Read vs Write Ratio

• Reads >> Writes (≈ 100:1)
  • Many users browse
  • Few actually book

3. Traffic Pattern

• Normal traffic → low
• Event drops (Taylor Swift, World Cup) → HUGE spike

👉 System must handle bursty traffic

4. Low Latency search

---

2️⃣ Core Entities

Keep it simple initially:

• Event
• Venue
• Performer
• Ticket

---

3️⃣ APIs Design

Map APIs → Functional Requirements

1. View Event

GET /events/{eventId} → Event & Venue & Performer & Ticket[]

2. Search Events

GET /events/search?term=&location=&date=&type= → Partial<Event> [ ]

3. Booking (2-Phase Process 🔥)

POST /booking/reserve
Body: { ticketId }

POST /booking/confirm
Body: { ticketId, paymentDetails }

---

4️⃣ HLD

ticket-master.excalidraw

Seat blocking

Issue:

• User reserves → leaves → seat blocked forever ❌

Solution 1: Timestamp + Query

• Add column reserved_at + check > 10 mins ❌ Messy logic

Solution 2: Cron Job

• Runs every 10 mins → release tickets from reserves to available

❌ Delta Delay issue of 10 min

✅ Best Solution: Distributed Lock (Redis 🔥)

👉 Goal: Prevent 2 users from reserving same seat at same time.

ticketId → locked (TTL = 10 min)
✔ Auto-expiry
✔ Clean design
✔ Scalable

SET ticket:101 userA NX EX 600

1. User Opens Event Page GET /events/101/tickets
2. Backend Checks DB SQL QUERY

Ticket	Status
1	available
2	booked
3	available

3. Backend Checks Redis Locks ticket:3 = userA (TTL left 7 min) Final Response to User

Ticket	Final UI State
1	available ✅
2	booked ❌
3	reserved ❌

---

What Actually Happens If Redis Fails?

1. ❌ Immediate impact:

• All active locks are lost
• System forgets reservations

👉 Result:

• Multiple users may try to book same ticket
• Temporary overbooking attempts

2. Why System Still Doesn’t Break Completely ?

Because: 👉 Final consistency is enforced by database (PostgreSQL)

DB Protection:

• ACID transactions
• Unique constraint on ticket

Example flow:

1. User A → payment success → tries to book
2. User B → also tries

👉 DB ensures: Only one transaction succeeds ✔ One wins
❌ Others fail

3. User Impact (IMPORTANT ⚠️)

• Users who thought they reserved → will lose it
• Some users:
  • Complete payment → get error ❌
  • Bad experience 😬

👉 This is called:

Consistency preserved, UX degraded

4. How to Handle This (Real Systems)

✅ Option 1: Redis High Availability (Basic Fix)

• Use Redis Cluster / Sentinel
• Replication + failover

✔ Reduces failure chance
❌ Still possible edge cases

✅ Option 2: Graceful Degradation

When Redis is down:

• Skip reservation step
• Allow direct booking

👉 DB becomes single source of truth

✔ System still works
❌ Higher contention

✅ Option 3: Retry + Compensation

If payment succeeds but booking fails:

• Refund automatically
• Show message:

“Seat already taken, amount well be refunded”

• ✔ Its common in real systems

---

4️⃣ Deep Dive

1. Deep Dive 1: Search Optimization - low-latency search

Problem:

SQL LIKE → full DB scan ❌

Solution:

• Move Search to search optimized database → Elasticsearch / AWS OpenSearch
• It builds inverted index to searching document by terms really quickly
• Fast text search
• Supports:
  • text
  • location
  • filters

Example

Event text:

Taylor Swift Live Concert Mumbai

Elasticsearch tokenizes into:

taylor
swift
live
concert
mumbai

Then maps:

swift -> [event1, event5]
concert -> [event1, event8]
...

So lookup becomes extremely fast.

Data Sync with primery data store:

1. Dual write (DB + ES) ❌
2. CDC (Change Data Capture) ✅ better

Popular Query / Hot Query search:

• Cashing - CDN (fastest for common API call) e.g GET /events/search?query=taylor+swift
• AWS Elastic Search has option - Node Query cashing
• Redis cache - betwen search service and elastic search

Strong Interview Answer

Initially I’d use SQL search for MVP, but for highly popular searches like Taylor Swift, full-table scans won’t scale. I’d move search to Elasticsearch/OpenSearch for inverted-index-based retrieval. Since search traffic is highly read-heavy and repetitive, I’d add CDN and Redis caching to absorb spikes. Search services would scale horizontally behind a load balancer, and API Gateway would enforce rate limiting to protect the system.

---