알림 읽음 처리에 대한 고민 (2025년 4월 29일)

2025년 4월 29일의 고민 노션에서 옮겨오고 있습니다

 

고민

 

알림을 읽을 때 마다 DB에서 update 쿼리를 요청하면 불 필요한 부하가 생긴다.

불 필요한 부하라기엔 필요한 로직일 수도 있지만 알림을 읽는다는 역할의 중요성을 생각해 보았을 때 차후에 만약 사용자가 많아진다면 대안을 생각하는 것이 필요한 부분이라고 생각한다.

당장은 사용자가 적어 문제가 되지 않지만 만약 사용자가 많아진다면? 스케일 아웃이나 스케일 업은 피할 수 없는 선택지가 되겠지만 그 선택을 하기전까진 대안과 최적화로 할 수 있는만큼은 기존 서버만으로 트래픽을 받고 싶다.

 

---

해결

알림 읽음과 삭제 상태를 프론트의 로컬 스토리지에서 관리하고 5분마다 서버로 전송하여 DB에 반영하는 방식을 선택했다.

그리고 사용자가 5분도 이용하지 않고 떠났을 때를 대비하여 로그아웃 로직 실행시 로컬 스토리지에 남아있는 상태들을 서버로 전송하여 마무리 하게 했다. 이로서 매번 DB를 업데이트 하지 않아도 된다.

 

다만 로컬스토리지는 새로고침할시에 초기화가 된다는 문제가 있다. 그래서 아직 5분이 지나지 않아 서버에서 최신 데이터를 가져와 알림이 살아날 수 있다. 그래서 만약 모두 읽기와 모두 삭제 버튼을 만들어 그 버튼을 눌렀을때는 즉시 DB에 반영되게 했다. 사용자들은 대부분 알림을 처리할때 전체적으로 처리하는 버튼이 있으면 그 버튼을 활용하는 경향이 있기 때문이다. 또한 그 버튼의 특성상 배치처리이기 때문에 서버에 주는 부하의 영향도 크지 않다.

 

하지만 여전히 새로고침을 하면 알림이 살아난다는 문제가 있기에 차후에 운영중에 문제가 발생하면 더 짧은 배치간격을 사용하거나 새로고침시 로컬 스토리지에 변경사항을 서버 데이터에 즉시 적용하는 방법을 사용할 것이다.