Katkat
Back

Design APIs for a Voting System

AppleSoftware Engineer · Technical Screen
EasySoftware EngineerTechnical ScreenSystem Design

Last updated

Define APIs and a core model for an authenticated election with one final ballot per voter and results hidden until close. The design discussion covers eligibility, deterministic timing, idempotent voting, concurrent submissions, recountable records, audit trails, and privacy boundaries.

Design APIs for a Voting System

Design the APIs and core data model for a voting system. Begin by clarifying the type of vote: identified or anonymous, single-choice or multi-choice, mutable or final, and whether partial results are visible before voting closes.

For a concrete baseline, assume authenticated voters, one final single-choice ballot per voter per election, a configured opening and closing time, and results that become public only after the election closes. Explain how the contracts would change if those assumptions change.

Part 1 — Model Elections, Options, and Eligibility

Define the resources and APIs needed to create an election, add options, configure eligibility and timing, publish it, and read its current state.

What This Part Should Cover

  • Stable election and option identifiers.
  • Draft, open, closed, and cancelled state transitions.
  • Authorization differences between administrators and voters.
  • Immutable voting rules once an election opens, or an explicit safe versioning policy.

Part 2 — Cast One Ballot Safely

Design the ballot endpoint, request and response fields, idempotency behavior, and error model. Address two concurrent requests from the same voter and a request racing with the closing time.

What This Part Should Cover

  • Authentication-derived voter identity rather than a trusted body field.
  • Validation of election state, eligibility, and selected option.
  • A uniqueness or transactional rule enforcing one ballot.
  • Stable idempotency for an ambiguous timeout without permitting a second choice.

Part 3 — Publish Results and Preserve Auditability

Define result and administrative APIs, explain how counts are produced, and show what operators can inspect without exposing individual votes unnecessarily.

What This Part Should Cover

  • Result visibility tied to election state.
  • Transactional counters or recountable immutable ballots.
  • Audit events for election changes and ballot acceptance decisions.
  • Privacy boundaries, rate limits, pagination, and monitoring.

Hints

Hint 1

Put rules in the election version: A ballot must be judged against the same option set and eligibility policy that the voter saw when casting it.

Hint 2

Make acceptance one transaction: The close-time check, eligibility decision, and one-ballot constraint must agree on one committed outcome.

Hint 3

Keep a recount path: Fast counters are useful for reads, but the system still needs an authoritative record that can detect or repair a count mismatch.

Follow-up questions

  • How would anonymous ballots change eligibility enforcement and audit storage?
  • What changes if voters may replace their ballot before close?
  • How would ranked-choice ballots affect validation and result computation?
  • How would you reconcile a materialized result counter with immutable ballot records?