Sada CRM election campaign platform built by SprintPattern

Sada

No platform could handle election-day load. So we built one. Three cycles, zero downtime.

Election campaigns fail on infrastructure, not ideas. Sprint built Sada to survive the one day of the year when every user shows up at once — and it did, three cycles running.

49
Campaigns Served

Total election campaigns run on the platform across its lifetime.

22
Running at Once

At peak, Sada managed 22 simultaneous campaigns with full stability and no service interruption.

0
Downtime Events

Despite thousands of concurrent users inside a few hours on election day, the system held without a single failure.

Pattern

The situation

Election campaigns run on coordination. Representatives need to register attendance, teams need to know where their people are, and organisers need lists that stay accurate while thousands of things change at once.

The tools available did the job until election day — and then fell over, exactly when failure costs the most. Sada was built to solve the version of the problem nobody else had solved: scale under concentrated, unforgiving load.

Sada was Sprint's own venture, built and operated in-house.

How we built it

Phase 1 — An MVP that tested the concept

We released the smallest thing that could prove the idea: simple pages where representatives register attendance and immediately see which committee they vote at, with printable reports for distribution. Enough to learn from, cheap enough to be wrong about.

Phase 2 — Direct selection from any device

The MVP worked, so we deepened it. Influencers could now interact with the database directly, view individuals in the system, and make selections from their phones. Sada stopped being a set of pages and became a real application, usable anywhere.

Phase 3 — Agent roles and oversight

We added a dedicated role for school agents, giving them the ability to monitor representative performance and movement in real time. Each release was shaped by what campaigns actually asked for during live use.

The technical problem worth talking about

Election traffic is not normal traffic. It arrives all at once, in a window measured in hours, and there is no second chance. This is precisely where competing platforms broke.

We treated scalability as an architecture decision rather than an optimisation to do later — choosing MongoDB, Node.js, and Redis specifically for the read and write patterns an election day produces, and designing the infrastructure around peak load rather than average.

The outcome

Sada served 49 election campaigns over its lifetime, ran 22 of them simultaneously at peak, held stable across three consecutive election cycles, and recorded zero downtime events under full load.

The lesson carried into everything Sprint has built since: infrastructure decisions made at the start are the ones you can't retrofit.

Pattern