For a pîtch competition attended by over 500 participants to vote for their best teams, I designed a custom voting system that could handle hundreds of simultaneous votes without losing data.
Key highlights:
Real-time updates with Server-Sent Events
Atomic vote counting using MongoDB’s $inc
Prevented duplicate votes with atomic check-and-set
Ensured only one team presents at a time using partial unique indexes
Handled 1,700+ votes across 5 teams with sub-200ms latency
The full article walks through the architecture, challenges, and solutions:
Impressive work Designing a system that reliably handles real-time voting at that scale is no small task.
I especially like the choice of Server-Sent Events for real-time updates—simple, efficient, and a great fit for one-way live data streams. Using MongoDB’s atomic $inc and check-and-set logic to prevent duplicate votes shows solid attention to data integrity under concurrency.
The partial unique index approach to enforce a single active presenting team is a clever solution as well—clean and enforceable at the database level instead of relying only on application logic.
Handling 1,700+ votes with sub-200ms latency in a live event environment is a strong result.
Uhhh, this is really cool, @Ahmed_Idani. I just read through your article and loved how you broke down the architecture and the challenges you ran into. Building a real-time voting system that can handle that many simultaneous users cleanly takes some solid engineering, and this is a great reference for anyone working on something similar.
Thanks for sharing this on the MongoDB Community Hub. How did the competition end up going?
The competition itself went really well! Voting stayed stable throughout the sessions, results updated in real time without inconsistencies, and we didn’t encounter any race-condition issues despite the traffic spikes. It was definitely a great stress test for the design.
Thanks again for taking the time to read and for the kind words — happy to dive deeper if there’s interest.