Section 7: One Transaction and One Deliberate Forgetting - Deep Dive: One Person, One Vote, Secret Ballot

Executive Summary: The interviewer hands you the wheel, and you go straight to the two invariants that make this a voting system rather than a form: once, and secret. Eligibility comes from the SSO token and a frozen roll. Exactly-once comes from a single transaction whose unique constraint makes a second ballot impossible at the database, with an idempotency key so a retry gets its original tracking code back. Secrecy comes from a pipeline that strips identity, coarsens time and shuffles ballots in batches of at least 25. Then you say plainly what that buys: strong protection against correlation by anyone without operator access to the servers, the write-ahead log or the backups, and no cryptographic guarantee.

About twenty-five minutes in, the interviewer puts the marker down. "You've got the boxes. Where do you want to go deeper?" At 1 vote/s peak there is nothing to scale, so you pick the part that can actually fail.

You: "Everything that matters about this system is in one transaction and one deliberate forgetting. I'd like to walk through both, and then be honest about where the forgetting stops."

Eligibility: Who You Are Comes From the Token

Alex signs in at 09:04 on day one. The API takes voter_id from the verified SSO token and nowhere else (Section 4 covers why the client never sends it). It looks Alex up in the roll, which is the registrar's snapshot imported and frozen when the election was scheduled. The roll row says two things: Alex is eligible, and Alex's ballot style. No row means 403 not_eligible. A participation row already present means 409 already_voted.