선물에서 조회수 시스템을 리팩토링합니다!

작성자

카테고리:

← 피드로
DEV Community · Seif Ahmed · 2026-08-18 개발(SW)

Seif Ahmed

In the past, link views were cached in Redis. After 10 seconds, all the views were flushed using a manual loop.

The old flow looked like this:

  • Loop through every key (ID).
  • Update its views separately via updateOne.
  • Move to the next until the loop ends.

Why This Is Wrong:

  • N+1 Problem: As the number of key operations grows, it runs many separate trips. Under very heavy traffic, the system can run out of resources and crash.
  • Duplicated Views: In this old flow, I never cleared the views, even after flushing them. This caused a duplicated view count.
  • No Validation: The system never checked if there were keys to update or not, running unnecessary empty operations.

The Fix:

Instead of running many separate updateOne operations, we group them into bulk operations using bulkWrite. This way, if we have 100 links viewed, we run 1 operation, unlike the 100 operation in the old system.

The New Flow:

  • Run hGetAll to get views.
  • Check if there is valid data to process. If not, skip this operation entirely.
  • Map the ID operations (Lightweight for niche apps like ours. I’m not trying to build something for billions, but a quick markdown previewer for devs like you).
  • Send the request to the database and update with bulkWrite.
  • If the request reaches the database and is acknowledged, delete the old views. This guarantees that if the server crashes midway, the data is not lost

Note: I added ordered: false because, by default, if one operation fails, the remaining operations are not executed and previous ones are not rolled back.

If you liked your 🎁, please consider giving it a star on GitHub

원문에서 계속 ↗