DEV Community

Puneet Khandelwal
Puneet Khandelwal

Posted on

Why Our Open-Source Election Visualizer Collapsed Under Load

When we launched our open-source campaign finance visualizer, we expected modest local traffic. We were wrong. Election night brought a surge of concurrent users refreshing the precinct map every second, and our database connection pool flatlined within minutes.

We love building civic tools that bring transparency to government spending. The frontend ran on React, the backend used Node.js containers, and everything pointed at a managed PostgreSQL instance. It looked clean in staging. It felt fast during dry runs with synthetic data. Local elections generate sudden, emotional spikes in public interest, though. When thousands of citizens hit the site simultaneously to check where candidate donations originated, our naive API design crumbled.

The primary failure point wasn't cloud compute limits. It was our data fetching strategy. Every incoming HTTP request triggered a complex JOIN across three large tables containing donor addresses, committee IDs, and transaction amounts. We assumed Postgres could handle the analytical queries in real time. We neglected to pre-aggregate the campaign totals into a materialized view.

Under load, these unindexed queries locked the transaction tables and caused timeouts across the entire application layer. The connection pool exhausted its slots, dropping incoming TCP handshakes. Citizens saw endless loading spinners instead of public data.

Fixing the bottleneck meant moving away from real-time relational queries for read-heavy public dashboards. We decoupled the write database from the read replicas, introduced Redis caching for hot endpoints, and shifted heavy aggregation tasks to a nightly cron job. Static JSON files generated during the build step now power the baseline UI. Live websockets only push incremental precinct updates now.

Civic software carries a unique public trust. When infrastructure fails during an active election cycle, it damages confidence in open data initiatives. Building for government transparency requires the same defensive engineering principles we apply to high-frequency trading or large-scale e-commerce.

If your civic tech stack cannot survive election night, the transparency it provides remains theoretical. We learned that engineering for the public sector means designing for the worst-case traffic distribution from day one. Scale testing with randomized load scripts is not optional when the public relies on your code to understand who funds their local representatives (field notes here).

Top comments (0)