fix(booking): synchronized + flush를 사용한 예매 중복 생성 방지

[khyaejin]

연관 이슈

• close [bug] 사전예매 API가 여러번 호출되어 예매가 중복되는 이슈 해결 #94

작업 내용

• 사전 예매 중복 이슈 감지 로직 추가 및 해결
• synchronized를 사용한 처리(단일 서버이기에 가능)
• 트랜잭션 커밋 타이밍으로 인한 중복을 방지하기 위해 예매 생성 후 flush()를 명시적으로 호출해서 즉시 DB에 반영하도록 수정
• synchronized (BOOKING_LOCK)을 사용하여 메서드 전체가 아닌 명시적 락 객체 사용

동작 원리

첫 번째 요청: BOOKING_LOCK을 획득 → 저장 → flush → 락 해제
두 번째 요청: 락 획득 → 중복 체크 → DB에 이미 있음 → 중복 감지 → 저장 안 함

1. 동시에 두개의 예매를 보낸 경우

• 프론트 응답
  : 둘 다 200

• 백엔드 로직 처리
  : 첫번째 예매는 정상처리, 두번째 예매는 중복 감지 후 저장하지 않음

• 디스코드 웹훅
  : 정상 처리 및 중복 감지 안내

• 문자
  : 첫번째 예매만 전송됨

2. 0.5초 간격으로 두개의 예매를 보낸 경우(1과 동일한 결과)

• 프론트 응답
  : 둘 다 200

• 백엔드 로직 처리
  : 첫번째 예매는 정상처리, 두번째 예매는 중복 감지 후 저장하지 않음

• 디스코드 웹훅
  : 정상 처리 및 중복 감지 안내

• 문자
  : 첫번째 예매만 전송됨

논의하고 싶은 내용

• 더 적절한 방법이 있다면 추후 리팩토링 시 반영하면 좋을 것 같습니다.

공유하고 싶은 내용

• 단일 서버이기에 synchronized를 예매 생성 메서드에 붙여 해결할 예정이지만, 이후 서버를 여러대로 확장하게 될 경우 Redis 분산 락이 필요합니다.

기타

• 기타 추가할 내용이 있다면 추가합니다.
• 없는 경우 삭제

[github-actions]

리뷰 내용

1. synchronized 사용

• 근거: createBooking 메서드에 synchronized 키워드를 사용했는데, 이는 단일 서버에서만 동작할 수 있는 방법입니다. 이후 서버 확장 시 Redis와 같은 분산 락을 사용하는 방안을 고려해야 한다고 설명하셨는데, 현재 상황에서 synchronized를 사용할 경우 성능에 부정적인 영향을 줄 수 있습니다.
• 수정 제안: 메서드 레벨의 동기화 대신, 보다 세밀한 락을 관리할 수 있는 방안을 검토してください. 예를 들어, 락 객체를 명시하여 사용하면 더 명확한 제어가 가능할 수 있습니다.

2. 중복 예매 체크 로직

• 근거: 중복 예매를 방지하기 위한 체크 로직이 잘 구현되었습니다. existsRecentBooking 메서드를 통해 최근 예매 여부를 확인하고 로깅 및 웹훅 알림을 발송하는 구조는 아주 좋습니다.
• 수정 제안: 중복 예매 체크 시 특정 시간(예: 3초) 이내에 대한 검사는 적절하나, 이 시간을 설정하는 부분을 상수로 분리하면 코드 가독성 및 유지보수성이 향상될 수 있습니다.

3. 코드 가독성

• 근거: 긴 로깅 메시지 포맷팅 부분은 가독성을 떨어뜨릴 수 있습니다.
• 수정 제안: 로깅 메시지를 빌더 패턴이나 별도의 메서드로 분리하면 가독성이 개선됩니다. 메시지의 포맷을 다루는 전용 메서드를 만드는 것도 고려해 보세요.

핵심 평가

변경사항이 잘 구현되었고 중복 예매 방지 로직이 효과적으로 작업되고 있습니다. 그러나 동기화 방법과 코드 가독성을 높이기 위한 추가적인 개선을 고려하면 더 나은 결과를 가져올 수 있을 것입니다.

[github-actions]

변경 사항 리뷰

1. 중복 예매 방지 구현

• 근거: 중복 예매 방지 로직을 효율적으로 추가한 점이 매우 좋습니다. existsRecentBooking 메서드의 도입은 예매 중복 확인에 기여합니다.
• 수정 제안: @Query를 사용할 때, 성능을 고려해 인덱스가 잘 설정된 필드를 사용하는 것이 좋습니다. 또한, createdAt 필드에 인덱스가 없다면 인덱스를 추가하는 것이 좋습니다.

2. 동기화 처리

• 근거: synchronized를 사용하여 예매 요청 간 동기화를 명확히 한 것은 좋은 접근입니다.
• 수정 제안: 나중에 서버를 수평 확장할 경우 대비하여 Redis 분산 락과 같은 대안도 고려하는 것이 좋겠습니다. 현재의 동기화 방식은 단일 서버 환경에 적합하지만, 시스템 확장성 측면에서 미래의 기술 스택에 대한 고민이 필요합니다.

3. 예외 처리 및 사용자 피드백

• 근거: 중복 예매 감지 시 로깅과 사용자에게의 알림 처리 작성이 매우 체계적입니다.
• 수정 제안: 중복 예매 발생 시 사용자에게 더 명확한 안내를 제공하기 위해 BookingDeadlinePassedException 예외를 사용할 수 있는 방법을 고려해보세요. 사용자에게 왜 예매가 실패했는지에 대한 정보를 구체적으로 전달하면 좋을 것 같습니다.

4. 코드 가독성

• 근거: 가독성을 높이기 위한 주석 작성이 잘 이루어졌습니다. 특히 각 단계별 주석이 있음으로써 코드 흐름을 이해하기 용이합니다.
• 수정 제안: 이에 더해, 특정 상수를 변수 이름으로 DUPLICATE_CHECK_SECONDS와 같은 명확한 이름으로 표현하였으나, 필요 시 설명 주석을 추가하여 더 명확한 이해를 돕는 것도 좋겠습니다.

핵심 평가: 전반적으로 중복 예매 방지 로직을 잘 구현하였고, 처리 과정이 명확하게 작성되었습니다. 그러나 향후 서버 확장성을 고려한 처리가 필요하며, 사용자에게 보다 명확한 피드백을 제공하는 방법을 고민하세요.