좌석 점유 API 요구사항

• 좌석 점유 API를 설계하는 과정에서 해당 API의 요구사항은 다음과 같이 설정하였다.
  • 여러 좌석 중 하나라도 이미 다른 사용자에게 점유돼 있으면, 나머지 좌석도 전부 점유에 실패해야 한다(all-or-nothing)

고려한 대안들

DB 낙관/비관락

• 좌석에 대한 결제/판매 상태 관리는 DB가 SSOT, 좌석의 5분 TTL 점유는 Redis에서 맡도록 역할을 나누었다. 점유를 DB 락으로 처리하면 이 구분이 무너지면서, 원래 Redis로 덜어내려 했던 부하가 다시 DB로 향한다.
• 콘서트 오픈 순간 좌석에 동시 접속이 몰리는데, 이를 DB 락으로 처리하려고 하면 소수의 ROW에 락 대기가 쌓이면서 성능 저하가 우려된다.

Redis 분산락

• 4개의 좌석을 요청한다고 가정하면, 4개의 키 획득을 각각 시도해야한다. 키 중 일부가 다른 스레드에 의해 점유되었다면 이는 데드락이며, Atomic한 작업이 아니다.

Redis Transaction

• Isolation은 보장되나, 작업이 중간에 실패해도 나머지 명령들이 그대로 실행되어 Atomic 하진 않다.
• 상세한 분기 처리 및 롤백이 불가능하다는 단점이 있다.