Design Voting at Scale

Voting is the little pair of arrows next to every post and comment on Reddit. Tap up or tap down, and the thing's net score (upvotes minus downvotes) moves, feeding into a user's karma and into where the post lands in a community's ranking. It looks like the simplest feature on the site. It is not. A single popular post in a large subreddit can draw hundreds of votes a second. Every one has to change a count and feed a ranking, and it has to survive people trying to rig it.

So the interesting design question is not "how do you add one to a number." The hard version shows up at scale. Adding one happens tens of thousands of times a second. The same user's vote can arrive twice on a flaky connection. The number decides what millions of people see next. And a whole economy of bots is trying to push that number in a direction real users did not. Scope the hour around those four pressures: the write path, idempotency, the ranking recompute, and integrity. The count itself is the easy part.

The Reddit angle

Reddit votes are not written to a counter on the request path, they are enqueued and folded in later, and saying that up front is the signal that you know how Reddit actually works. Reddit's own architecture pushes expensive operations, casting a vote and submitting a link, onto an async job queue (historically RabbitMQ) rather than doing them inline. A worker pulls the vote off the queue, updates the aggregate in a store chosen for availability (Cassandra), and recomputes the ranking. That shape lets the user's tap return immediately while the real work happens behind it. It is also why Reddit's scores wobble on refresh and settle a moment later. A synchronous "increment the row" fights the design Reddit shipped. "Enqueue the vote, ack the user, reconcile async, counts are eventually consistent by design" is Reddit's house style.