Refactoring the views system in YOUR gift!

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