Design the APIs for an Election Voting System
Design the APIs and the core data model for a voting system. Start by saying which kind of vote you are designing for — identified or anonymous, single or multiple choice, final or changeable, results visible during voting or only afterwards — then commit to a baseline.
Baseline: voters are authenticated; each voter may cast one final, single-choice ballot per election; an election has a configured opening and closing time; results become public only after it closes. Be ready to say how the contracts change when each assumption changes.
Work through three parts. Elections: the resources and endpoints to create an election, add options, configure eligibility and timing, publish it and read its state — including its lifecycle and who may do what. Casting a ballot: the endpoint, its request and response, its error model, and what happens with a retry after a timeout, two simultaneous requests from one voter, and a request that races the closing time. Results and audit: when results are visible, how counts are produced, and what operators can inspect without exposing how individuals voted.
The coding version of this question — a service class with idempotent votes and an audit log — is Voting System API.
Hints
Hint 1
Freeze the rules when the election is published. A ballot has to be judged against the option set and eligibility policy the voter actually saw, so either make those immutable once open or record the rules version on every ballot.
Hint 2
Acceptance is one transaction: the is-it-open check, the eligibility decision and the one-ballot uniqueness constraint must commit or fail together, using the database's clock rather than each app server's.
Hint 3
Fast counters are for reads. Keep immutable ballots as the authoritative record so a count can always be recomputed and a mismatch detected and repaired.
Asked at
Sign in to talk to the interviewer — ask what's in scope, what scale to design for, or for a nudge when you're stuck. Conversations save to your account.