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

Get Kaizen Chandra’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

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