인프런 커뮤니티 질문&답변

일단 포인트의 경우 수정이 자주 발생할까? 부터 생각해봤는데요, 포인트는 상품을 결제하거나 취소할 때, 리뷰를 작성할 때 발생하겠더라구요. 그리고 그 중에서도 충돌이 발생하려면 포인트 수정이 동시에 일어나야 하는데, 그런 상황은 일반적인 사용 패턴에서는 자주 발생하지는 않을 것 같아요. 굳이 예를 들자면 폰으로는 새로운 상품을 결제하고 컴퓨터로는 리뷰를 작성하는 경우...? 그치만 애초에 이런 상황은 자주 발생하지는 않을 것 같아요.
만약 포인트 잔액을 비관적 락을 사용해서 관리한다면 데이터 정합성이나 일관성은 더 확실하게 보장될 수 있겠지만, 애초에 충돌이 자주 발생하지 않는 영역인데 비관적 락을 사용하면 상대적으로 성능이 떨어질 수 있겠다는 생각이 들었습니다.
낙관적 락을 사용한다면 비관적 락보다 상대적으로 성능이 좋아서 웬만한 경우에는 문제가 없지만, 특수한 케이스에서 충돌이 발생하여 데이터 불일치가 발생할 수도 있을 것 같아요. 근데 이런 상황은 자주 발생하지는 않을 것 같고, PointHistoryEntity 같이 포인트 변경 이력을 저장해둔다면 그런 상황에서 해당 데이터를 이용해서 복구할 수 있지 않을까 싶습니다.
정리해보면, 비관적 락을 사용하냐 낙관적 락을 사용하냐는 '데이터의 정합성에 대한 보장' 과 '성능' 중에서 어떤 부분을 선택하냐에 따라 다를 것 같다! 인 것 같습니다.
일단 나름 생각해봤는데...맞게 생각한건지는 모르겠네요ㅜ

많이 고민해보셨군요! 훌륭합니다! 잘 생각 하신 것 같아요 👍

우선 적어주신 것 처럼 일반적인 상황에서 경합이 잦게 발생하지 않는 부분입니다
다만 어뷰징에 대한 것도 생각을 해보면 좋겠습니다! 누군가 서비스의 취약점을 찾아서 포인트를 무제한으로 쓰려고 결제를 동시에 한다던가 하는 상황도 있을것 같습니다

그치만 그것 또한 애초에 어뷰징이고 문제가 발생해도 당사자는 할말이 없기 때문에 큰 부분은 아니라고 봅니다

또 적어주신 것 처럼 낙관적락을 사용하는게 일반적으로 성능이 좋기 때문에 가능한 낙관적락으로 접근하는게 맞다고 생각합니다

그럼 다시 원래 질문으로 돌아와서 같이 답변해드리면

대체로 어느 정도 규모가 있는 서비스에서도 낙관적 락만으로 해결이 되는 것인지도 궁금합니다.

제 의견은 그럴수도 있고, 아닐 수도 있다 입니다.

적어주신 것 처럼 생각을 계속 해보시면 이 문제는 서비스의 규모를 생각하기 보다는 경합 규모의 문제입니다 (물론 이게 서비스의 규모와 연관은 있지만요)

즉 유저 기반으로 1인이 스스로 처리하는 무엇인가는 애초에 경합이 발생할 가능성이 낮습니다, 그치만 포인트에서도 포인트 송금 기능이 생긴다면 어떻게 될까요?

이제 그러면 경합의 가능성은 유저수에 비례합니다(정확히는 유저의 포인트를 가진 액티브 지인 수가 팩터겠죠)

그래서 적어주신 것 처럼 '데이터의 정합성에 대한 보장' 과 '성능' 도 적절한 관점이지만

어떤 락을 선택할 것이냐는 경합의 규모 부터 판단해보면 선택지를 좀 더 좁힐 수 있다고 생각합니다.

이미 잘 생각하셨지만 이런 관점을 더하여 더 고민해보시면 좋을 것 같습니다! 😃

모쪼록 답이 되었길 바랍니다! 감사합니다! 😃

좋은 설명 감사합니다! 답 해주시기 전에 생각할 시간을 주시니까 평소보다 더 깊게 생각해보게 되는 것 같아요! 남은 강의도 잘 들어보겠습니당

완강 후 수강평도 기대하겠습니다!