Skip to content
Personal

Concert Reservation Service

2024-10-05 — 2024-11-30

Concert seat reservation service resolving concurrency across seat locking, payments, and point charging under 10K concurrent requests — hybrid locking strategy (optimistic + Redisson distributed lock), 15x TPS improvement via Redis caching, Kafka event-driven architecture, K6 load test-driven optimization

Concert Reservation Service project cover image

Project Description

A project that resolved concurrency issues in high-traffic environments using multiple locking strategies (pessimistic, optimistic, and Redis distributed locks), selecting the optimal approach per scenario. Designed a hybrid strategy applying optimistic locks for seat reservation and Redisson-based distributed locks for point charging and payments. Optimized read performance through Redis caching and DB indexing, and reduced system coupling with Kafka-based event-driven architecture. Experienced the full cycle of identifying and resolving performance bottlenecks through K6 load testing.

Highlights

  • 50% seat reservation response time improvement with optimistic locking (10K concurrent)
  • Hybrid locking strategy: optimistic lock for seats, Redisson for payments
  • 15x TPS improvement (100 → 1,500), 94% DB query reduction via Redis caching
  • Kafka event-driven architecture eliminating inter-domain coupling
  • Performance bottleneck identification and resolution via K6 load testing

Features

  • Seat reservation — optimistic lock-based seat preemption, auto-release after 5-min payment timeout
  • Point charging & payment — Redisson distributed lock ensuring balance consistency under concurrent operations
  • Queue system — Redis Sorted Set-based waiting queue with polling-based position lookup
  • Redis caching — cache layer on concert/seat queries, TPS 100→1,500 (15x), 94% DB query reduction
  • Kafka event-driven — reservation completion events published via Kafka, eliminating payment/notification domain coupling
  • K6 load testing — per-scenario performance measurement under 10K concurrent requests, bottleneck identification and lock strategy comparison

Lessons Learned

  • Understood fundamental differences in concurrency control by comparing pessimistic, optimistic, and distributed lock tradeoffs
  • Learned context-driven selection over single solutions through hybrid locking strategy design per scenario
  • Experienced layered caching strategy maximizing read performance by combining Redis caching with DB index optimization
  • Learned async communication design eliminating inter-domain coupling through Kafka-based event-driven architecture

Tech Stack

Java Spring Boot JPA Redis MySQL Kafka Docker K6

Related Posts

  • JPA Pessimistic Lock, Optimistic Lock and Retry
  • Spring Boot Concert Reservation Concurrency Analysis
  • Distributed Lock Implementation with Spring Boot Redis
  • Cache and Caching Strategy

Related Links

  • erd
  • api Spec
  • sequence Diagram
  • requirements
  • project Structure
  • concurrency Analysis
  • caching Strategy
  • index Optimization