Section 11: The Ballot That Stays on Paper - Evolution II: A United States National Election

Executive Summary: The interviewer's last requirement change is the biggest: a United States presidential election. The weak answer multiplies the university numbers and adds shards. The Staff answer notices that scale is the easiest problem left, and that the hard ones (nation-state adversaries, a secret ballot nobody has to trust an operator for, coercion, and public confidence) are not solved by any online casting design experts accept today. So you change the scope. Ballots stay on paper, run by states and local jurisdictions, and you design what software is actually good for here: election-night results reporting at about 833,000 requests per second, and a voter lookup service. The lesson: sometimes the senior move is to redraw the boundary of the system, not to grow it.

Interviewer: "Great. Now it's the United States presidential election. Same service?"

The Pushback: "Just Scale It"

The tempting reply writes itself. Go from 30,000 ballots to about 160 million, from one database to a sharded cluster, from one region to three. Every box in Section 6 gets a bigger number.

You: "I'd like to push back before I draw anything. The throughput is the part I'm least worried about. About 160 million ballots is a large number, but large web systems handle more writes than that. What changes is everything Section 7 called the honest limit. Our secret ballot works because we trust the people running the server. At a college the threat is a curious admin. Nationally it is nation-state adversaries, and the people running the server are themselves a target."

Interviewer: "So add the cryptography you mentioned. End-to-end verifiable, mixnets, all of it."

You: "That fixes one wall and leaves three. Remote voting still can't stop someone watching a voter's screen or buying their vote, which is the coercion problem from Section 10, now at national stakes. Every voter's device becomes part of the trusted base. And the result has to convince people who don't trust the software or its operators. I'd also lean on the expert position here: the US National Academies of Sciences, Engineering, and Medicine's 2018 report Securing the Vote recommended human-readable paper ballots and risk-limiting audits, and advised against returning marked ballots over the internet until strong security guarantees exist. I'm not going to out-design that in an interview."

Interviewer: "Then what do you build? You can't just say no."

You: "Right. I'd change the scope. First I'll describe what the system actually is, then design the parts where software helps."

The flip trigger is written down: if strong security guarantees for internet return of ballots ever exist, independently verified and accepted by experts, revisit. Until then, the ballot does not touch our servers. A few states already allow electronic ballot return for limited groups, such as some military and overseas voters; that's the narrow practice the National Academies cautioned against, not a model to scale.

Quick check before moving on: