Requirements and Constraints

Voting systems must prevent duplicate ballots, resist tampering, and survive traffic spikes on election night.

Unlike likes on a post, votes are legally and socially sensitive. The architecture must make certain attacks impossible (double vote) and others detectable (ballot box stuffing at scale).

Threat model first

Define adversaries: duplicate voter, admin tampering, DDoS, network partition during close. Each drives different controls.

In practice

Estonia's i-Voting uses cryptographic protocols; US precinct systems often air-gap tallies. Product web polls (Twitter, Slack) use idempotent voter keys and Redis rate limits — weaker but appropriate for low stakes.

Key Takeaways

One voter → one ballot: unique constraint on (election_id, voter_id).
Ballots should be append-only; tallies derived, not edited in place.
Secret ballot vs verifiability is a product/legal trade-off.
Rate limiting and bot detection at the edge.
Audit logs: who cast when (metadata), not necessarily how they voted.
Read scaling for results pages; write spike at poll close.

integrityauditrate limitingappend-onlythreat model

Back-of-the-Envelope Estimation →