</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

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_style already 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

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.