Section 1: The Write That Must Forget Who Wrote It - Problem Understanding & Clarifications

Executive Summary: This section covers the first ten minutes of a voting-service interview. The prompt looks small: one college, a few thousand students, a ballot and a results page. What makes it hard is not volume. A vote is the one common write that must check exactly who you are, accept you once, and then keep no link back to you. We name the four properties every election needs (eligible, once, secret, counted correctly), ask the clarifying questions that pin down the college's scope, write the answers down as assumptions, and note, without designing for them yet, the two requirement changes the prompt has already announced.

The interviewer reads the prompt aloud:

"Design an online voting service for our college's student elections. Then we'll see how it changes if the whole university, with all its colleges, uses it. And at the end: what if it were a United States election?"

Two instincts show up right away, and both are wrong. The first says this is a form and a table, ten minutes of work. The second hears "United States" and starts drawing Kafka. The prompt has three parts on purpose. The interviewer is telling you the requirements will change twice, and is watching whether you design for the system in front of you while staying honest about the ones coming next.

Why a Vote Is Not Just Another Write

Think about the writes you already know how to design. An order, a comment or a like is stored against the person who made it, forever, and that link is the point. An anonymous survey goes the other way: it never knows who answered, so anyone can answer twice.

A vote has to do both. At the door, the system must know exactly who you are, because only eligible students may vote and each may vote once. A moment later it must forget, because nobody, including the people who run the system, should be able to find out how you voted. Authenticate, accept once, then make the ballot unlinkable from the person.

Key Insight: A vote is the only everyday write that must be tied to an identity to be accepted and cut loose from that identity to be stored. Almost every design decision in this topic follows from holding both requirements at once.

The contrast with the sibling module Like Counter System Design makes this concrete. Counting likes looks like counting votes, but almost every property is reversed:

Here is the life of one vote, with the step that makes this problem unusual in the middle:

Each property has a matching failure that the design has to rule out:

Quick check before moving on: