🎫 티켓팅 서비스 전제 정리

• 기능별 좌석 상태 변경 과정 (예매 가능 여부를 TRUE/FALSE로 표시)
  • 예매: 예매 가능(좌석 상태: TRUE) → 예매 대기(10분)(좌석 상태: FALSE) → 결제 완료(예매 확정)(좌석 상태: FALSE)
  • 예매 취소: 예매 확정(좌석 상태: FALSE) → 예매 취소(좌석 상태: TRUE)
  • 기타: ‘예매 대기’ 상태에서 10분 초과 시 자동 해제(좌석 상태: FALSE → TRUE)
• 발생할 수 있는 문제

  • 같은 좌석에 대해 동시에 여러 사용자가 예약 요청

  • 결제 지연(10분)으로 인해 락 유지 시간이 길어질 수 있음

    ⇒ 락은 좌석 상태를 TRUE → FALSE로 전환하는 ‘순간’만 보호, 결제 대기 상태 유지는 별도의 비즈니스 로직(스케줄러)으로 관리

🔧 동시성 제어 방법별 장단점과 최종 선택 방안

1. 비관적 락

장점 : DB 차원에서 중복 예약을 원천 차단하기 때문에 안전성이 가장 높음

단점 : 트래픽 집중 시 대기 발생

<aside>

트래픽 집중 시나리오 예시

1. 동일 좌석에 대해 100명의 사용자가 예매 요청
2. 첫 번째 요청만 Row Lock을 획득 후, 좌석 상태를 TRUE → FALSE로 변경
3. 나머지 요청들은 동일 Row에 대한 Lock 획득을 위해 DB 대기 큐에서 순차적으로 대기
4. Lock을 획득한 요청들은 이미 FALSE인 좌석 상태를 확인한 후 즉시 실패 처리

⇒ 결과가 이미 정해진 요청들까지 DB 커넥션과 트랜잭션을 점유하게 됨

</aside>

2. 낙관적 락

장점 : 비관적 락과 달리 대기열이 없고, 즉시 성공 또는 즉시 실패 처리가 가능함

단점 : 인기 좌석의 경우 update 충돌이 빈번하게 발생하여, DB write 트래픽과 트랜잭션 비용 증가

<aside>

1. 100명의 사용자가 한 자리에 대한 예매 요청
2. 1번 사용자의 요청 처리 후 version 업데이트
3. 나머지 99개의 요청은 update 시도 → version mismatch → rollback </aside>

3. 분산 락 (Redis 기반)

장점 :

• 불필요한 DB 부하를 줄이는 데 효과적(트래픽이 집중되는 상황에서 DB 접근 이전에 경쟁을 제어 가능)
• 락의 소유 상태와 만료 시간을 중앙에서 관리 → 분산 환경에서도 락 상태 명확하게 파악 가능

단점 : Redis 장애 발생 시 락 기능이 영향을 받을 수 있으므로, 이중화 구성이나 장애 대응 전략 필요

최종 결론

Redis 분산 락은 DB 진입 전 트래픽을 컷하기 위한 1차 필터로 사용 + 최종 데이터 무결성은 DB row 단위 비관적 락으로 보장