Redis vs MongoDB로 본 상품별 실시간 조회자 수 집계

상품 상세 페이지에서 중복되지 않은 사용자 수를 실시간으로 보여주기 위해, 웹과 앱 모두에 같은 방식으로 적용 가능한 API 기반 조회 구조를 고민한다. 트래픽이 빠르게 몰리는 상황이라 RDB 대신 NoSQL을 후보로 두고, 그중 Redis와 MongoDB를 비교한다.

Redis에서는 여러 자료구조를 검토한다.

• Set: 상품번호를 키로 두고 사용자 식별 정보를 저장하는 방식은 단순하지만, 브라우저 종료 감지 실패나 네트워크 문제로 삭제가 누락되면 데이터가 남는다.
• Set + Expire: 만료 시간을 두면 정리는 쉬워지지만, 60초 동안 아무도 보지 않아야 삭제되는 구조라 실시간 정확도가 크게 흔들린다.
• Set + Hash: 별도 배치로 이탈 감지 실패 데이터를 지울 수 있지만, 전체 상품과 사용자 정보를 순회해야 해 O(N) 부하가 커진다.
• Sorted Set: 사용자별 시간값을 점수로 저장하고 ZREMRANGEBYSCORE로 오래된 항목을 지울 수 있어 가장 균형이 좋다. 다만 배치로 모든 상품을 훑어야 하므로 완전히 가볍지는 않지만, 편의성과 성능을 고려해 이 방식을 선택한다.

MongoDB에서는 두 가지 설계를 비교한다.

• 첫 번째는 userProductView처럼 상품번호, 로그인 ID, timestamp를 upsert하는 방식이다. 상품별 문서 수로 집계를 구할 수 있지만, 검색 최적화를 위한 index와 사용자 수 동기화를 위한 TTL(expire) 설정을 함께 고민해야 한다.
• 두 번째는 한 상품 문서 안에 users 배열을 넣는 방식이다. 구조는 단순하지만 배열이 커질수록 순회와 갱신 비용이 늘고, 자주 조회되는 상품은 문서가 계속 커져서 결국 Batch Job 정리가 다시 필요해진다.

정리하면, 실시간성과 여러 도메인에서의 조회 제공까지 생각하면 Redis가 더 적합해 보이지만 비용이 크다. 반대로 MongoDB는 배치가 없어 유지보수는 쉬울 수 있지만, 인덱스와 만료 설정을 더 세심하게 다뤄야 한다. 결국 어떤 DB가 정답이라기보다, 요구사항과 운영 부담을 함께 보고 선택해야 한다는 결론에 도달한다.