Pašvaldību vēlēšanu IT fiasko: kas nogāja greizi un ko darīt citādi

1. Kas notika un kāpēc izgāzās

Galvenais trūkums	Ko atklāja vēlēšanu nakts
Sasteigta nodošana	Sistēma ekspluatācijā tika iedota tikai 1 dienu pirms vēlēšanām – nebija laika pilnai slodzes un drošības pārbaudei.
Nepareizs "rate limiter"	Drošības slānis bloķēja likumīgus iecirkņu pieprasījumus, radot ķēdes reakciju un "karoties" serveriem.
Centralizēts OCR mezgls	Biļetenu attēli (≈ 100 KB × 600–800 tūkst.) gāja uz vienu galveno serveri; bez paralelizētas apstrādes tas sāka smakt pie pīķa slodzes.
Nav rindas/buferēšanas	Iecirkņu dati "piedzina" backendu, jo netika izmantoti prioritāri job-queue vai message-brokeri (RabbitMQ/Kafka).
Formāls atbalsts	Incidentu eskalācija risinājās WhatsApp čatā, nevis ar 24/7 SOC/monitoringu.
Nereāls budžets	Piešķirtie 1,81 M EUR atļāva MVP, bet ne valsts mēroga, kļūmēm noturīgu sistēmu.

2. Nauda: cik bija un cik objektīvi vajadzēja

Pozīcija	Izlietots (2025)	Adekvāti kritiskai infrastruktūrai
Analīze + dizains	≈ 0,18 M	0,30 M
Izstrāde (OCR, API, UI)	≈ 0,45 M	0,90 M
Serveri + glabātuve	≈ 0,27 M	0,60 M
Drošības/slodzes testi	≈ 0,18 M	0,30 M
Apmācība + dokumenti	≈ 0,18 M	0,25 M
24/7 atbalsts	(ietilpa kopbudžetā)	0,20 M
Vadība + audits	≈ 0,27 M	0,40 M
Kopā	1,81 M EUR	≈ 3,5–4,0 M EUR

Tipiska peļņas marža pie valsts iepirkumiem: 15–30 %. Pie 4 M EUR budžeta uzņēmumam (vai konsorcijam) paliktu 0,6–1,0 M EUR pēc algu un infrastruktūras izmaksu segšanas.

3. Tehniskais skats "kā bija" vs. "kā vajadzēja"

Komponents	Faktiski (iespējams)	Ieteicamā prakse
DB	Viena PostgreSQL/SQL Server instance, bez klasterēšanas	Klasterēts PostgreSQL vai Oracle RAC + Redis buferis
Failu glabāšana	NFS diskos, nekompresēti JPG/PDF	Ceph/S3 ar gzip/zip, checksum + verzionēšana
OCR	ABBYY/Tesseract uz viena 32 vCPU servera	Docker mikropakalpojumi × 10–20 mezgli (auto-scale)
Rate limiting	IP-balstīts slieksnis	Token-balstīta kvota, adaptīvs uz slodzi
Monitoring	Sistēmlogi + manuāls WhatsApp	Prometheus + Grafana + Alertmanager, SOC komanda
CI/CD	Manuāla deploy, vēls integrācijas posms	GitLab CI, IaC (Terraform/Ansible), staging + prod vides
Tests	Ierobežoti JMeter skripti	Gatling/JMeter simulējot 1000 iecirkņu, ≥ 2k requests/s

4. Cik laika vajadzēja

Minimāli uzticams grafiks: 8–12 mēneši
- 1–2 mēn. analīze
- 4 mēn. izstrāde
- 2 mēn. integrācija + slodzes/drošības testi
- 1 mēn. ģenerālmēģinājumi, apmācība
Latvijā reālā izstrāde praktiski "saspiesta" <6 mēnešos, ar nodošanu dienu pirms vēlēšanām.

5. Galvenā atbildība

Loma	Par ko atbild	Piezīme
VDAA (Valsts digitālās attīstības aģentūra)	Iepirkums, projektu pārraudzība, ekspluatācijas nodošana	Kritiski novērtēja slodzes riskus un termiņus par zemu
VARAM (politiskā uzraudzība)	Budžets, termiņu kontrole, starpinstitucionālā koordinācija	Akceptēja nodošanu pēdējā brīdī
CVK (Centrālā vēlēšanu komisija)	Lietotāja prasības, sistēmas pieņemšana	Pieņēma sistēmu bez pilna ģenerālmēģinājuma validācijas
Galvenais līgumizpildītājs (nosaukums publiski slēpts)	Izstrāde, testēšana, atbalsts	Pieļāva arhitektūras un slodzes dizaina nepilnības
Apakšuzņēmēji (OCR, hosting)	Specializētie moduļi, datu centrs	Noslēgti "melno kastu" līgumi, trūkst caurspīdības

6. Pieci konkrēti padomi nākamajām vēlēšanām

Budžets ≥ 4 M EUR, ar 20 % rezervi neparedzētam infrastruktūras pieaugumam vēlēšanu nedēļā.
Atvērt mikroservisu arhitektūru, balstītu uz Docker + Kubernetes, lai varētu horizontāli mērogot OCR un API mezglus dažu minūšu laikā.
Pilna slodzes simulācija (≥ 2 k pieprasījumi/s) vismaz 60 dienas pirms vēlēšanām; atkārtot pēc katra koda "major" laidiena.
Neatkarīgs drošības audits un "red-team" tests ar DDoS, SQL-injection, identificācijas zādzību scenārijiem.
24/7 incidentu pārvaldības centrs ar reālu "runbook": restarti automatizēti, push-paziņojumi iecirkņiem, nevis WhatsApp improvizācija.

Municipal Elections IT Fiasco: What Went Wrong and What to Do Differently

1. What happened and why it failed

Main Deficiency	What election night revealed
Rushed handover	The system was put into operation only 1 day before the elections — no time for full load and security testing.
Incorrect rate limiter	The security layer blocked legitimate precinct requests, causing a chain reaction and server overload.
Centralised OCR node	Ballot images (≈ 100 KB × 600–800 thousand) were routed to a single main server; without parallelised processing it began to choke under peak load.
No queue / buffering	Precinct data overwhelmed the backend, as no priority job-queues or message brokers (RabbitMQ/Kafka) were in place.
Informal support	Incident escalation happened via WhatsApp chat rather than a 24/7 SOC / monitoring system.
Unrealistic budget	The allocated 1.81 M EUR was enough for an MVP, but not for a national-scale, fault-tolerant system.

2. Money: what was available vs. what was objectively needed

Item	Spent (2025)	Adequate for critical infrastructure
Analysis + design	≈ 0.18 M	0.30 M
Development (OCR, API, UI)	≈ 0.45 M	0.90 M
Servers + storage	≈ 0.27 M	0.60 M
Security / load tests	≈ 0.18 M	0.30 M
Training + documentation	≈ 0.18 M	0.25 M
24/7 support	(included in total budget)	0.20 M
Management + audit	≈ 0.27 M	0.40 M
Total	1.81 M EUR	≈ 3.5–4.0 M EUR

Typical profit margin on government contracts: 15–30 %. With a 4 M EUR budget, the company (or consortium) would retain 0.6–1.0 M EUR after covering salaries and infrastructure costs.

3. Technical view: "as it was" vs. "as it should have been"

Component	Actual (likely)	Recommended practice
DB	Single PostgreSQL/SQL Server instance, no clustering	Clustered PostgreSQL or Oracle RAC + Redis buffer
File storage	NFS disks, uncompressed JPG/PDF	Ceph/S3 with gzip/zip, checksum + versioning
OCR	ABBYY/Tesseract on a single 32-vCPU server	Docker microservices × 10–20 nodes (auto-scale)
Rate limiting	IP-based threshold	Token-based quota, adaptive to load
Monitoring	System logs + manual WhatsApp	Prometheus + Grafana + Alertmanager, SOC team
CI/CD	Manual deploy, late integration stage	GitLab CI, IaC (Terraform/Ansible), staging + prod environments
Testing	Limited JMeter scripts	Gatling/JMeter simulating 1000 precincts, ≥ 2k requests/s

4. How much time was needed

Minimum reliable schedule: 8–12 months
- 1–2 months: analysis
- 4 months: development
- 2 months: integration + load/security tests
- 1 month: rehearsals, training
In Latvia, actual development was effectively compressed to <6 months, with handover one day before elections.

5. Main responsibility

Role	Responsible for	Note
VDAA (State Digital Development Agency)	Procurement, project oversight, operational handover	Critically underestimated load risks and deadlines
VARAM (political oversight)	Budget, deadline control, inter-institutional coordination	Accepted last-minute handover
CVK (Central Election Commission)	User requirements, system acceptance	Accepted the system without full dress-rehearsal validation
Main contractor (name withheld publicly)	Development, testing, support	Allowed architectural and load-design deficiencies
Subcontractors (OCR, hosting)	Specialised modules, data centre	Black-box contracts, lack of transparency

6. Five concrete recommendations for next elections

Budget ≥ 4 M EUR, with a 20 % reserve for unforeseen infrastructure scaling during election week.
Open microservice architecture based on Docker + Kubernetes, enabling horizontal scaling of OCR and API nodes within minutes.
Full load simulation (≥ 2k requests/s) at least 60 days before elections; repeated after every major code release.
Independent security audit and red-team test covering DDoS, SQL-injection, and identity-theft scenarios.
24/7 incident management centre with a real runbook: automated restarts, push notifications to precincts — not WhatsApp improvisation.