[Fix] - 서로 다른 테이블에 중복 저장되는 여행기 좋아요 정보의 정합성 취약점 해결

[Libienz]

✅ TO-DO LIST

• 여행기 좋아요 정보 정합성 취약점 해결

🙈 참고 사항

반정규화를 통해 조회속도를 상당히 빠르게 할 수 있었지만 중복 저장되는 데이터는 정합성이 깨질 위험이 있습니다. 현재 저희 로직에서도 데이터 정합성 취약점이 존재합니다.

예시

• 1번 여행기의 좋아요가 2개인 상황
• 사용자 A와 B가 동시에 1번 여행기에 좋아요를 요청
• 사용자 A의 트랜잭션 내에서 1번 여행기를 가져옴 (좋아요 2개)
• 사용자 B의 트랜잭션 내에서 1번 여행기를 가져옴 (좋아요 2개)
• 사용자 A와 B의 요청을 모두 처리하고 난 후 1번 여행기의 좋아요 개수는 3개 (4개여야함)

이를 해결하기 위해 조회에 대한 잠금이나 네이티브 쿼리(UPDATE), Sync Schedule등의 해결책을 고려할 수 있습니다. 방법을 비교해보겠습니다.
조회에 대한 잠금이나 네이티브 쿼리로 UPDATE하는 방식은 정합성이 실시간으로 유지되지만 잠금을 사용하기에 성능 부분에서 취약합니다.
Sync Schedule은 실시간으로 정합성이 보장되지는 않지만 잠금을 사용하지 않아 성능에서 우수합니다. 다만 여행기가 많아지면 많아질수록 주기마다 다뤄야하는 데이터 크기가 커지기 때문에 확장성 부분에서도 다소 취약합니다.

현재 어떤 방식을 택할지 고민 중인데 스크럼 시간에 얘기드리겠습니다. 제가 내린 결론은 PR로 말씀드리겠습니다.