Section 8: Twelve Front Doors, One Ballot Box - Evolution I: The University with Many Colleges
Executive Summary: The interviewer changes the requirements: Northfield is now a university with 12 colleges, 60,000 students and 3,000 students enrolled in two colleges at once. Load grows to 5 votes/s and 3,000 results requests/s, still small. What changes is who a voter is and what they may vote on: identity becomes one stable person id behind a university IdP, eligibility becomes per race through electorates, one election carries 51 races in about 32 ballot styles, admins are scoped to their college, and roll amendments close 7 days before voting opens. The transaction, the split stores and the static results stay. A requirement change is graded on what you keep as much as on what you add.
The interviewer puts the marker down on the college diagram and draws a bigger box around it.
Interviewer: "Good news. The election committee liked it, and now the whole of Northfield University wants it. Twelve colleges, 60,000 students. One election: a university president, a couple of university referenda, and each college's own races. Some students belong to two colleges. What changes?"
You: "Let me sort it into three piles: what stays, what changes, and what v1 already left room for. Then I'll spend the time on the changes, because two of them can quietly break one person, one vote."
Stays, Changes, Already Ready
First the numbers, from Section 3's growth table. 60,000 eligible at 50% turnout is 30,000 ballots over 72 hours. The opening blast brings 4,500 votes in 15 minutes: 4,500 ÷ 900 s = 5 votes/s at peak. At about 2 KB per ballot the election is 60 MB. Results reach 3,000 requests/s after close. Availability tightens to 99.95%, about 2.2 minutes of downtime across the window, and results are due within 30 minutes of close, ranked-choice count included.
| Verdict | Why | |
|---|---|---|
| Cast transaction (participation insert with a unique key, plus the ballot buffer insert) | Stays | 5 votes/s is nothing for one relational database. Section 7's mechanism is unchanged |
| Split stores, shuffled flush, no precise timestamps | Stays | Secrecy doesn't depend on size. More ballots per batch mix better |
| One managed relational database, multi-AZ, no queue or cache on the vote path | Stays | 60 MB and 5 votes/s. "Shouldn't it be Kafka now?" gets Section 3's answer |
| Results as a static file on a CDN | Stays | 3,000 requests/s is an edge problem, and the origin writes one file |
What changes is identity, eligibility, the ballot and admin scope, each below. The third pile earns the credit, because it shows v1 left doors open:
- SSO, not our own passwords. Federation changes the identity provider, not our login code.
ballot_stylealready exists on the roll and every ballot. One style becomes about 32, with no change to the anonymous ballot.- Elections already own races. Adding an electorate between them is one new table.
- The roll was already a snapshot, read at cast time rather than live from the registrar.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson