Movie Ticket Booking (MTB) System Design Architecture — AWS Infra 99.99% Availability

Movie Ticket Booking Platform

• B2B Component: Theatre partners can onboard and manage their operations
• B2C Component: End customers can browse and book movie tickets
• Key Challenge: Handle concurrent bookings across multiple countries with high availability (99.99%)

POC Source Code: Github

1. Executive summary (Goals & constraints)

Primary goals:

• High availability (99.99%)
• low-latency booking
• consistent seat inventory handling across regions
• multi-country support
• secure payments and PCI compliance
• cost-efficient at scale.

Key non-functional requirements:

• P95 API latency < 200ms, booking confirmation < 3s
• booking success rate > 99%
• cache hit ratio > 90%, horizontal scalability
• multi-region active-active with automatic failover.

Traffic assumptions (design targets): 10M active users, 1M bookings/month, peak concurrent users 100k+, target >1k bookings/sec at peak.

2. High-level architecture (components & AWS mappings)

Summary flow (user → services):

1. Client (mobile / web) → Route53 → CloudFront (static + SPA) → AWS Global Accelerator / API Gateway → Regional ELB → EKS (microservices) / Lambda → Data stores (RDS/DynamoDB/Redis) + Event bus (MSK/EventBridge) → Notifications (Pinpoint/SNS/SES) → Observability & Security.

Key AWS services:

• Edge & DNS: Route 53, CloudFront, Global Accelerator
• WAF & DDoS: AWS WAF, AWS Shield Advanced
• API / Ingress: API Gateway (edge or regional), Elastic Load Balancer (ALB) fronting EKS.
• Compute: Amazon EKS for stateless & stateful microservices; AWS Lambda for asynchronous workers, webhooks, small tasks.
• Caching & locks: Amazon ElastiCache for Redis (Cluster Mode) — seat locks, session caching, leaderboard/metadata.
• Primary RDBMS: Amazon RDS (Postgres / Aurora Postgres) — transactional booking data, theatre metadata (multi-AZ).
• NoSQL: Amazon DynamoDB — high-scale lookup data (e.g., user session index, booking details, idempotency store).
• Streaming & events: Amazon MSK (Kafka) for event-driven flows + Amazon EventBridge for cross-account/region events.
• Messaging/notifications: Amazon Pinpoint
• Storage: Amazon S3 (static assets, DL archives, backups), Glacier for archival
• Observability: CloudWatch, X-Ray, CloudTrail, optional APM (Datadog/NewRelic).
• Security: AWS KMS for keys, Cognito for user auth (or custom OIDC), AWS Secrets Manager for credentials, IAM policies and SCPs.

Logging: Centralized logs via CloudWatch and an ELK / OpenSearch stack if required.

3. Detailed design

3.1 Deployment topology — Multi-region active-active

• Deploy full stack into at least 2 active regions per major geography (e.g., ap-south-1 & ap-northeast-1, us-east-1 & us-west-2, eu-west-1 & eu-central-1).
• Route53 uses Latency + Geolocation policies to send users to nearest healthy region. Health checks and failover policies configured per endpoint.
• Global Accelerator for a single static anycast IP and optimal routing to the nearest edge and regional endpoint.
• Data residency: some data (PII) is region-bound; design each region to accept local writes when necessary and replicate/synchronize where allowed.

3.2 Microservice boundaries

• Auth Service (Cognito or custom) — user sign-up, MFA, tokens (OIDC).
• Theatre Management (B2B) — theatre onboarding, screen/seat mapping, schedule management.
• Movie Browsing — catalog, search (Elasticsearch/OpenSearch), metadata.
• Booking Service — booking lifecycle (initiate, hold, confirm, cancel, refund). Core transactional service.
• Payment Service — integrates with PCI-compliant payment gateway (Stripe/Adyen etc.) — tokenize card data, not store CVV.
• Notification Service — email, SMS, push via Pinpoint/SNS/SES.
• Reservation Locker — seat locking & TTL using Redis (fast).
• Reporting / Analytics — streaming consumer that writes to data lake (S3/Glue/Redshift) or OLAP.
• Billing & Invoicing — partner settlements for B2B.
• Admin Panel & B2B Portal — separate UI & APIs for theatre partners.

3.3 Booking flow (HLD -> LLD)

Synchronous + Event-driven hybrid:

1. Browse & Select Seats: Client requests seat map; service retrieves seat availability aggregated in Redis (fast). If cache miss, read DB and populate cache.
2. Initiate Booking / Reserve Seats (fast path):

• Client calls POST /bookings/initiate with showId, seatIds, userId.
• Booking Service attempts to acquire locks on seatIds via Redis SETNX or Lua script (atomic): lock key = lock:showId:seatId with TTL (e.g., 5 minutes).
• If all locks acquired, create a provisional booking record with status PENDING_PAYMENT in RDS (transaction), and store idempotency token.
• Return booking reference + payment token to client; start countdown TTL.

1. Payment: Client performs payment through Payment Service (tokenized). Payment Service returns success/failure and emits event to MSK and EventBridge.
2. Confirm Booking: On payment-success event:

• Booking Service reconfirms locks; marks booking CONFIRMED in RDS, persists final seat occupancy, releases locks, writes event to MSK for analytics.
• Notify user via Notification Service.
• Reserve data synchronized to DynamoDB/Cache to support fast reads.

1. Payment Failure / Timeout:

• If payment fails or timeouts: Booking Service cancels PENDING_PAYMENT, releases seat locks (Redis), updates DB; notify user. The seat becomes available.

1. Idempotency & Retry: All write endpoints accept idempotency tokens and are idempotent. Payment webhooks and asynchronous event consumers must handle duplicate events.

Seat lock implementation details:

• Use Redis cluster with strong consistency in each region.
• Use Lua script to atomically check and set multiple seat locks in a single call (avoid race).
• Use TTL <= maximum payment timeout (e.g., 5–15 minutes). TTL expiry automatically frees seats.

3.4 Concurrency & consistency patterns

• Booking transaction uses pessimistic locking at seat-level (via Redis) to prevent double allocation.
• Eventual consistency for secondary views (analytics, search index) via Kafka/MSK consumers.
• Strong consistency for final booking state kept in RDS/Aurora with ACID transactions.
• Read scaling: read replicas and read-only caches (ElastiCache + CDN).
• Concurrent booking across regions: region-local seat locking, cross-region replication of booking events to central store. For global shows, use a single region ownership or central seat master to avoid split-brain for the same show. Prefer sharding shows to region owners per theatre (single source of truth).

3.5 Data stores & schema

• Primary transactional DB: Aurora PostgreSQL (Multi-AZ, read replicas). Partition bookings by region/country or by theatre (LIST partitioning) for scale and locality. Example table snippet (from your doc):
• DynamoDB: idempotency token store, quick lookup items, session index for mobile connectivity; global tables if needed cross-region.
• Redis (ElastiCache): seat locks, seat-availability cache (show inventory), session cache, rate-limit counters.
• OpenSearch / Elasticsearch: movie & theatre search & filter.
• S3: static content, backups, uploads, DL exports.
• Data lake: S3 + Glue for analytics.

3.6 API contract (summary)

• POST /v1/bookings/initiate — body: {userId, showId, seatIds[], idempotencyKey} → returns bookingReference, expiresAt, paymentUrl.
• POST /v1/bookings/confirm — body: {bookingReference, paymentId} → returns booked details.
• GET /v1/shows/{showId}/seats — returns seat map with status (available/held/booked).
• POST /v1/theatres (B2B) — onboard theatre; requires admin auth.
• POST /v1/payments/webhook — receives payment provider webhook (idempotent).

All APIs must support idempotencyKey, throttling headers, tracing headers (X-Trace-Id).

ER Diagram & Database Schema Design (PostgresSQL)

4. Reliability & 99.99% Availability strategy

4.1 Multi-region active-active

• Deploy to >=2 active regions per geography. Use Route53 and Global Accelerator for traffic steering and failover.
• Stateful components (RDS/Aurora) are replicated via cross-region read replicas and asynchronous replication for DR. Consider Aurora Global Database for low-latency cross-region read and fast recovery.

4.2 Availability patterns

• Autoscaling for EKS worker nodes (Karpenter / Cluster Autoscaler) and HPA for pods.
• Use multi-AZ for every stateful layer (RDS Multi-AZ, ElastiCache across AZs).
• Circuit breakers and bulkhead patterns in services to isolate failures.
• Chaos Engineering and regular failure drills.

4.3 Failover timelines (example)

• Health check detects region failure (10s).
• Route53 failover shift (TTL dependent): use low TTL (30s) + Global Accelerator reduces global time to failover.
• Warmed replicas in DR region (autoscaling) spin up within minutes; use pre-warmed capacity for critical paths.

4.4 Disaster recovery

• Backups: continuous automated snapshots (RDS), S3 lifecycle to Glacier.
• RTO & RPO targets: RTO < 15 minutes for core services, RPO < few minutes using cross-region replication and event streaming.
• Runbook: documented playbooks for DB failover, DNS failover, and manual rollback.

5. Scalability & performance optimizations

5.1 Caching

• Multi-layer caching: CloudFront (frontend), API Gateway caching, ElastiCache Redis, application-level caches.
• TTLs: inventory short TTLs (30s), show metadata 5–15 mins.

5.2 DB & query optimizations

• Partition bookings by region/theatre. Use composite indexes on (show_id, seat_id).
• Read replicas for read-heavy traffic, write masters per shard.
• Use prepared statements, batching, and connection pooling (HikariCP tuned as in doc).

5.3 Async processing

• Use MSK for events: booking.initiated, booking.confirmed, payment.success, booking.cancelled.
• Consumers: notification, settlement, analytics, search-index updates — decoupled for resilience.

5.4 Cost-optimizations

• Reserved instances & Savings Plans as baseline.
• Use spot instances for batch/analytics.
• Right-size DB instance classes and cache sizes.
• Archive old bookings to S3/Glacier.

6. Security & compliance

6.1 PCI & payment

• Use third-party PCI-compliant payment providers. Tokenize card data; do not store CVV nor raw PAN.
• Quarterly scans & annual audit.

6.2 Network & data security

• Use TLS 1.3 for all traffic. mTLS for service-to-service if feasible.
• IAM least privilege; use roles for services and KMS for encryption.
• PII: encrypt at rest (AES-256 via KMS), store EU data only within EU regions to meet GDPR.

6.3 DDoS protection & WAF

• AWS Shield Advanced + WAF rules to block common vectors.
• Rate limiting per IP and per user (API Gateway + app-layer counters in Redis).

6.4 Monitoring & observability

• Tracing: AWS X-Ray + distributed tracing headers.
• Metrics: CloudWatch custom metrics (booking success, lock latencies, cache hit ratio, DB Q time).
• Logging: centralized logs with retention & alerting. Set alerts for error spikes and availability drops.
• Security monitoring: CloudTrail for audit, GuardDuty for threats.

7. Operations, SLOs, Runbooks & Alerts

7.1 SLO / SLA targets

• Availability: 99.99% (monthly).
• Booking success: > 99%.
• P95 latency: < 200ms.

7.2 Key alerts & thresholds

• Critical: API error rate >1% for 5m, RDS connection exhausted, payment gateway down, overall availability <99.9%.
• Warning: P95 > 500ms, CPU > 80% for 10 min, Cache hit < 80%.
• Info: slow queries, unusual traffic patterns.

7.3 Runbooks (examples)

• Payment gateway outage: divert users to retry queue + show appropriate UI message; notify SRE; page on-call.
• DB failover: promote cross-region replica using Aurora Global DB failover playbook; run consistency checks.
• Cache cluster failure: failover to replicas; if full Redis cluster down, fallback to DB reads with throttling.

8. Observability & testing

• Canary deployments + feature flags for new features.
• Synthetic monitoring (booking flows) executed from multiple geographies.
• Load testing: run pre-release load tests to validate >1k bookings/sec.

Chaos experiments: periodic pod/region failure tests.

9. Cost estimate

Monthly baseline (10M users, 1M bookings): ~$50k–$60k (compute, DB, cache, storage, networking). With reserved instances & savings: ~$35k/month. (See your uploaded cost breakdown for details.)

10. Low-level artifacts (LLD pointers & code snippets)

10.1 Redis seat-lock Lua (pseudo)

- Attempt to lock multiple seats atomically
 - KEYS: lock keys for each seat
 - ARGV[1] = lock value (bookingRef)
 - ARGV[2] = ttl seconds
for i=1,#KEYS do
if redis.call('exists', KEYS[i]) == 1 then
return 0
end
end
for i=1,#KEYS do
redis.call('set', KEYS[i], ARGV[1], 'EX', ARGV[2])
end
return 1

• Release script checks ownership before deleting lock.

10.2 Booking table partition example

Release script checks ownership before deleting lock.

11. Sequence diagrams (textual) — Booking success & failure

Success path

1. Client → BookingService /initiate (idempotencyKey)
2. BookingService → Redis (lock seats via Lua)
3. BookingService → RDS create PENDING_PAYMENT booking
4. BookingService → Payment gateway (create payment session)
5. Client completes payment → Payment gateway → webhook → PaymentService
6. PaymentService emits payment.success to MSK/EventBridge
7. BookingService consumes payment.success → mark booking CONFIRMED in RDS → release seat lock
8. BookingService → NotificationService → send ticket
9. BookingService → produces booking.confirmed event for analytics

Timeout/failure

After TTL or payment.failed, BookingService cancels booking and releases locks; notifications sent.

12. Testing & validation

• Unit & Integration tests for seat locking, transactions, and idempotency.
• End-to-end tests for booking scenarios (concurrent holds).
• Load tests to validate expected TPS and latency.

Security tests including penetration testing and PCI compliance scans.

MOVIE TICKET BOOKING SYSTEM — PRODUCTION CHECKLIST

Service Design

• Stateless Spring Boot services

• Clear B2C (users) and B2B (theatres) boundaries

• Redis used only for ephemeral state (locks, cache)

• PostgreSQL used for source of truth

• Kafka used for async workflows only

• Outbox pattern implemented for event reliability

• No cross-service DB access

Domain Integrity

• Seat locking uses Redis SETNX + TTL

• Booking state machine enforced

INITIATED → PENDING_PAYMENT → CONFIRMED / EXPIRED

• All state transitions are idempotent

• No business logic in controllers

DATA & TRANSACTION SAFETY (POSTGRES)

Schema & Constraints

• Unique constraint on (show_id, seat_number)

• Unique booking reference

• Foreign keys for all relations

• Monetary values stored as NUMERIC

• UTC timestamps everywhere

Transactions

• Booking creation is single DB transaction

• Outbox event saved in same transaction

• No Kafka publish inside DB transaction

• Pessimistic locking avoided for hot paths

Data Lifecycle

• Booking expiry scheduler enabled

• Old bookings archived (partition / TTL strategy)

• GDPR deletion flow available

REDIS (LOCKING & CACHE)

Seat Locking

• Redis cluster (3+ nodes)

• SETNX + TTL used for locks

• TTL ≥ booking expiry time

• Ownership check before unlock

• Lock key format standardized

LOCK:SEAT:{seatId}

Cache Usage

• Cache only read-heavy data (shows, seats)

• Never cache booking state permanently

• Cache invalidation via Kafka events

• Redis eviction policy: allkeys-lru

KAFKA & OUTBOX PATTERN

Outbox

• Outbox table indexed by status

• Events written inside booking transaction

• Background publisher enabled

• Retry with exponential backoff

• Dead-letter handling for FAILED events

Kafka

• Topic partitioning by bookingReference

• At-least-once delivery acknowledged

• Consumers are idempotent

• Schema versioned (Avro / JSON schema)

• Message size limits enforced

Topics

• booking.initiated

• booking.confirmed

• booking.expired

• payment.completed

PAYMENT FLOW SAFETY

Payment Integration

• Payment is fully asynchronous

• Webhook endpoints are idempotent

• No blocking on payment gateway

• Duplicate payment protection via reference ID

• Automatic refund on confirmation failure

PCI Compliance

• No card data stored

• Tokenization only

• Secure webhook verification

• Audit logs enabled

SECURITY

API Security

• JWT authentication enforced

• Role-based authorization (USER / ADMIN)

• Ownership check for booking access

• Rate limiting enabled

• CAPTCHA for suspicious traffic

Data Security

• TLS everywhere

• DB encryption at rest

• Secrets stored in Vault / KMS

• Logs sanitized (no PII)

PERFORMANCE & SCALABILITY

Load Handling

• Tested for 10K+ concurrent users

• Booking latency < 200ms P95

• Seat lock acquisition < 50ms

• Connection pools sized correctly

Scaling

• Horizontal pod autoscaling enabled

• Redis and Kafka scaled independently

• Read replicas used for queries

• No N+1 queries

⸻

MONITORING & OBSERVABILITY

Metrics

• Booking success rate

• Seat lock failures

• Booking expiry rate

• Kafka lag

• Redis lock contention

• Payment failure rate

Logs & Tracing

• Correlation ID per request

• Structured logs (JSON)

• Distributed tracing enabled

• Slow query logs enabled

⸻

FAILURE & RESILIENCE

Failure Scenarios Tested

• Redis restart during booking

• Kafka outage

• DB failover

• Payment gateway downtime

• Partial network failure

Recovery

• Locks auto-expire

• Bookings auto-expire

• Outbox retries events

• Graceful degradation enabled

⸻

DEPLOYMENT & OPERATIONS

CI/CD

• Zero-downtime deployments

• Blue-green or canary rollout

• Database migrations versioned

• Rollback strategy defined

Config

• All configs externalized

• Feature flags for risky changes

• Environment parity ensured

BUSINESS & SLA READINESS

SLAs

• Availability ≥ 99.99%

• Booking accuracy 100%

• Zero double bookings

• Refund SLA defined

Reporting

• Booking revenue tracking

• Conversion metrics

• Seat utilization metrics