## 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. ```hint 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. ``` ### 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. ```hint Make acceptance one transaction The close-time check, eligibility decision, and one-ballot constraint must agree on one committed outcome. ``` ### 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. ```hint 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. ``` ### What a Strong Answer Covers - Gives concrete resource, ballot, and result contracts with meaningful status codes. - Enforces one accepted ballot under retries and concurrency. - Makes opening and closing boundaries deterministic. - Separates public results, administrative audit data, and protected voter information. ### Follow-up Questions 1. How would anonymous ballots change eligibility enforcement and audit storage? 2. What changes if voters may replace their ballot before close? 3. How would ranked-choice ballots affect validation and result computation? 4. How would you reconcile a materialized result counter with immutable ballot records?