Refactoring the views system in YOUR gift!

In the past, link views were cached in Redis. However, after 10 seconds, all the views were flushed using a manual loop. This old flow involved looping through every key (ID), updating its views separately via updateOne, and moving on to the next until the loop ended.

There were several issues with this approach. First, it suffered from the N+1 problem, as the number of key operations grew, causing many separate trips. Under heavy traffic, the system could run out of resources and crash. Additionally, views were never cleared even after flushing, resulting in duplicated view counts. Another problem was that the system never checked if there were keys to update, leading to unnecessary empty operations.

To address these issues, the fix involved grouping updateOne operations into bulk operations using bulkWrite. This way, instead of running 100 updateOne operations for 100 viewed links, only one bulk operation would be executed. The new flow began with running hGetAll to get views. The system would then check if there was valid data to process.

If not, it would skip the operation entirely. Next, it mapped the ID operations, which were lightweight for niche apps like this one. The request was then sent to the database for update with bulkWrite. If the request reached the database and was acknowledged, the old views were deleted. This ensured that even if the server crashed midway, the data would not be lost.

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