최초 Room 엔티티 조회 시, select for update 패턴으로 x-lock 을 걸고 room 엔티티 조회하도록 코드 수정
lock 대기 시간을 최대 5초로 설정 & 최대 3회 재시도 하도록 제한 (spring retry 활용)
재시도 횟수 초과한 요청에 대해서는 HTTP 423(Locked) error throw



이렇게 수정한 후, 테스트 코드 실행하면 아래와 같이 데이터 정합성이 맞아지는 것 확인

부하 테스트를 실행해도 5xx error 는 0건이 나오고, 방 정원 수 만큼만 ‘방 참여 성공’ 응답을 받는 것 확인 (DB에 기록된 데이터 정합성도 문제없음)
→ 총 500건의 요청 중, 모임방 참여 성공 응답 : 9건, 모임방 참여 실패 - Resource Locked : 491건
→ 5xx error : 0건
하지만, select for update 패턴으로 인한 DB 락 대기로 인해 서버의 처리율이 떨어져 목표로 했던 ‘p(95) 1초 이내’ 는 달성하지 못함



최초 Room 엔티티 조회 시, select for update 패턴으로 x-lock을 획득한 후 엔티티 조회하도록 제한하니
는 해결되었음
하지만 500명의 사용자가 동시에 참여 요청을 보낼 경우, p(95)가 약 9.5초가 나옴
비관적 락으로 인한 병목을 제거하기 위해, 낙관적 락 기반의 이벤트 분리 구조로의 전환이 필요함