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