Ketika Data Pemilu Tidak Bisa Diakses: Saatnya Bicara Arsitektur Sistem yang Sesungguhnya

Bayangkan ini: Anda baru saja selesai mencoblos. Pulang ke rumah, membuka laptop, lalu mencoba mengecek apakah suara Anda sudah masuk ke sistem KPU. Hasilnya? Layar putih. Atau tulisan yang cukup familiar: “Website sedang dalam pemeliharaan.”

Itulah yang dialami jutaan warga Indonesia pada dua pemilu terakhir. Bukan sekali. Bukan kebetulan. Dan ini bukan sekadar masalah teknis biasa.

Dua Pemilu, Satu Masalah yang Sama

Pemilu 2019: Sejarah Berulang

Sesaat setelah pencoblosan Pemilu 2019 selesai pada 17 April, situs kpu.go.id dan pemilu2019.kpu.go.id kolaps. Warganet ramai-ramai mengeluhkan hal ini di Twitter. Situs real count KPU tidak bisa diakses justru di momen paling krusial — ketika publik paling ingin tahu.

Komisioner KPU saat itu, Pramono Ubaid Tanthowi, memberikan penjelasan singkat: “Kalaupun hari ini atau beberapa saat lalu down, itu karena memang traffic-nya sangat tinggi. Orang penasaran setelah diombang-ambingkan oleh hasil quick count yang diterima secara berbeda-beda.”

Tidak hanya real count. Bahkan situs DPT lindungihakpilihmu.kpu.go.id pun sudah lumpuh sejak H-2 pemilu. Bagi pemilih yang ingin memastikan namanya terdaftar, tidak ada akses. Tidak ada fallback. Tidak ada alternatif yang memadai. Relawan IT KPU saat itu mengakui ada dua masalah sekaligus: sistem yang masih diperbaiki di tengah jalan, dan lonjakan trafik yang tidak terantisipasi.

Pemilu 2024: Masalah Lebih Kompleks

Lima tahun berlalu, sistem berganti nama menjadi Sirekap, teknologinya diperbarui, anggarannya lebih besar. Namun pada 14 Februari 2024, cerita yang sama kembali terulang.

kpu.go.id tidak bisa diakses sejak H-1 pemilu. Pada hari pencoblosan itu sendiri, hingga pukul 16.00 WIB website KPU masih menampilkan pesan “website sedang dalam pemeliharaan.” Komisioner KPU Mochamad Afifuddin mengakui situs memang sempat down, dengan alasan banyaknya masyarakat yang mengakses — jutaan orang secara bersamaan, terutama yang ingin mengecek lokasi TPS.

Anggota KPU RI Betty Epsilon Idroos menambahkan bahwa situs utama KPU mengalami serangan DDoS dalam jumlah yang sangat besar, bahkan hingga ratusan juta serangan. Tim keamanan siber CISSReC yang mencoba mengakses menggunakan VPN dari Singapura, Australia, dan Jepang pun tetap tidak berhasil. Yang menarik: saat dilakukan pengecekan ping, server KPU masih merespons — artinya server hidup, tapi layanan webnya yang tidak bisa diakses.

Lalu ada masalah lain yang tidak kalah serius. Pada 5 Maret 2024, grafik data rekapitulasi suara di Sirekap tiba-tiba menghilang. Diagram batang perolehan suara partai dan caleg tidak lagi ditampilkan. Publik hanya bisa melihat foto formulir C-Hasil. Menurut Tempo, penutupan akses grafis ini terjadi tepat saat tudingan dugaan penggelembungan suara sedang ramai dibicarakan.

Dua Penyebab Sistem Down: Teknis dan Non-Teknis

Saya ingin jujur di sini. Sebagai praktisi IT yang selama ini bergelut di dunia sistem informasi pemilu, ada dua kategori penyebab yang perlu dipahami secara terpisah, karena solusinya pun berbeda.

Penyebab Pertama: Teknis

Ini adalah masalah yang bisa diselesaikan dengan perencanaan yang matang dan infrastruktur yang tepat. Beberapa skenario teknis yang umum terjadi:

Underprovisioning kapasitas server. Server disiapkan untuk beban rata-rata, bukan beban puncak. Ketika jutaan orang mengakses secara bersamaan dalam hitungan jam, server kolaps.
Tidak ada auto-scaling. Infrastruktur tidak dirancang untuk menambah kapasitas secara otomatis saat trafik melonjak.
Single point of failure. Semua trafik diarahkan ke satu titik. Ketika titik itu bermasalah, seluruh sistem ikut jatuh.
Serangan DDoS tanpa mitigasi memadai. Tanpa WAF (Web Application Firewall) dan sistem anti-DDoS yang proper, ratusan juta request palsu bisa melumpuhkan layanan yang sah.
Database bottleneck. Data masuk dan data keluar melewati jalur yang sama, sehingga proses input dari petugas TPS berkompetisi dengan permintaan publik yang membaca data.
Tidak ada CDN (Content Delivery Network). Data ditarik langsung dari satu server pusat, bukan dari node terdekat ke pengguna.
Deployment buruk. Melakukan pembaruan sistem di hari H pemilu — sesuatu yang terindikasi dari pesan “website sedang dalam pemeliharaan” yang muncul tepat saat dibutuhkan — adalah kesalahan manajemen risiko yang serius.

Penyebab Kedua: Non-Teknis (Politis)

Ini yang lebih sulit dibicarakan, tapi perlu dikatakan dengan jernih.

Ketika grafik suara di Sirekap tiba-tiba hilang pada 5 Maret 2024 — tepat saat polemik penggelembungan suara sedang memanas — ini bukan keputusan teknis. Ini keputusan kebijakan. KPU sendiri mengonfirmasi bahwa perubahan tampilan dilakukan secara sengaja.

Dalam konteks yang lebih luas, ada skenario yang secara logis perlu diakui keberadaannya: ada kepentingan tertentu yang tidak ingin data suara per TPS bisa diakses secara terbuka dan real-time oleh publik. Ketika data per TPS bisa dilihat oleh siapa saja — termasuk lawan politik dan pemantau independen — maka ruang untuk mengubah angka di tingkat PPK menjadi sangat sempit, karena setiap perubahan bisa langsung dikroscek.

Jika kasusnya adalah ini, maka tidak ada solusi teknis yang bisa menyelesaikannya. Infrastruktur sebagus apapun tidak akan diaktifkan jika ada keputusan di level atas untuk membatasi akses. Ini bukan kegagalan engineer — ini kegagalan tata kelola dan integritas sistem. Dan justru karena itu, transparansi teknis menjadi semakin penting: sistem harus dirancang sedemikian rupa sehingga keputusan untuk menutup akses pun meninggalkan jejak yang bisa diaudit.

Jika Kita Serius Membangun Sistem yang Tahan Jutaan Pengguna

Sekarang, mari kita masuk ke inti pembahasan. Jika ada 180 juta lebih warga Indonesia yang memiliki hak pilih, dan bahkan hanya 1 persen saja yang ingin mengakses data hasil pemilu secara bersamaan — itu sudah lebih dari 1,8 juta pengguna aktif serentak. Ini bukan angka kecil. Ini setara dengan traffic platform e-commerce nasional pada hari harbolnas.

Sistem seperti ini membutuhkan desain yang tidak bisa dikerjakan setengah-setengah.

Prinsip Fundamental: Pisahkan Jalur Data Masuk dan Data Keluar

Ini mungkin saran terpenting yang bisa saya berikan, dan ironisnya paling sering diabaikan.

Data masuk adalah aliran dari petugas KPPS di setiap TPS yang menginput hasil penghitungan melalui aplikasi mobile. Ini adalah operasi write yang membutuhkan validasi, autentikasi ketat, dan konsistensi data.

Data keluar adalah apa yang dibaca oleh jutaan warga yang ingin melihat hasil. Ini adalah operasi read dalam volume masif.

Jika kedua jalur ini melewati sistem yang sama, keduanya akan saling membebani dan saling mengganggu. Solusinya adalah memisahkan mereka secara arsitektural:

Server operasional (untuk input data dari TPS) terpisah sepenuhnya dari server publik.
Data dari server operasional diekspor secara berkala — misalnya setiap 5 atau 15 menit — menjadi data statis yang kemudian di-publish ke sistem distribusi publik.
Data publik yang disajikan bukanlah query live ke database utama, melainkan snapshot yang sudah diproses dan dikemas menjadi file statis (JSON, misalnya) yang bisa di-cache dan didistribusikan lewat CDN.

Dengan cara ini, bahkan jika server publik diserang DDoS sekalipun, server operasional tempat petugas TPS menginput data tetap berjalan normal. Dan sebaliknya, beban jutaan pembaca tidak mengganggu proses perekaman data.

Arsitektur Sistem yang Direkomendasikan

Layer 1: Input Data — Server Operasional (Private Cluster)

Ini adalah “dapur” sistem. Tidak boleh terekspos langsung ke publik.

Spesifikasi Server Input (Per Node):

CPU: AMD EPYC 9754 128-Core atau Intel Xeon Platinum 8592+ (64 core)
RAM: 512 GB DDR5 ECC
Storage: NVMe SSD 4 TB (RAID 10) + Cold Storage HDD 40 TB untuk arsip
Network: Dual 100 Gbps fiber uplink dengan redundansi penuh
Deployment: Minimum 5 node aktif dalam konfigurasi active-active cluster, dengan 2 node standby hot

Database Cluster (Untuk Data Operasional):

PostgreSQL dengan konfigurasi multi-master (menggunakan Patroni + etcd)
Replikasi synchronous ke minimal 3 node
Automatic failover kurang dari 30 detik
Backup incremental setiap 5 menit, full backup setiap hari

Middleware & Queue:

Apache Kafka untuk message queue antara TPS dan server pusat
Setiap data dari TPS masuk sebagai event yang diproses secara asinkron
Jika koneksi TPS terputus, data tersimpan di antrian dan dikirim saat koneksi pulih

Layer 2: Proses Transformasi — ETL Engine

Ini adalah komponen yang mengubah data dinamis dari server operasional menjadi data statis yang siap dipublikasikan.

Fungsi:

Setiap interval waktu yang ditentukan (misalnya 10 menit), engine ini mengambil snapshot terbaru dari database operasional
Memproses dan mengagregasi data: per TPS, per kecamatan, per kabupaten/kota, per provinsi, nasional
Mengekspor hasilnya ke format JSON/Parquet yang dioptimalkan
Mendistribusikan hasilnya ke layer berikutnya

Teknologi:

Apache Spark atau dbt untuk transformasi data berskala besar
Airflow untuk orkestrasi dan penjadwalan
MinIO atau AWS S3-compatible storage untuk menyimpan output statis

Layer 3: Distribusi Publik — CDN Cluster (Public Layer)

Ini yang berhadapan langsung dengan jutaan pengguna.

Prinsip utama: Tidak ada query langsung ke database. Semua yang disajikan ke publik adalah file statis yang di-cache.

Spesifikasi Server CDN Edge (Per Node):

CPU: AMD EPYC 9554 64-Core
RAM: 256 GB DDR5
Storage: NVMe SSD 8 TB (untuk cache layer)
Network: 400 Gbps fiber uplink

Konfigurasi:

Minimum 20 node CDN tersebar di seluruh Indonesia: Jakarta (5 node), Surabaya (3), Medan (3), Makassar (3), Balikpapan (2), Denpasar (2), Manado (1), Jayapura (1)
Load balancer menggunakan Anycast routing — pengguna otomatis diarahkan ke node terdekat
Cache hit ratio target: > 99% — artinya hanya 1% request yang perlu menyentuh origin server
TTL cache untuk data per TPS: 10 menit (sinkron dengan interval refresh ETL)
TTL cache untuk data agregat nasional: 5 menit

Origin Server (Backup di balik CDN):

10 server origin dengan spesifikasi tinggi
Nginx sebagai web server dengan konfigurasi tinggi
Redis cluster untuk in-memory cache tambahan

Layer 4: Anti-DDoS dan Keamanan Jaringan

Arsitektur Network:

Internet
    ?
    ?
[BGP Anycast — IP Publik Didistribusikan ke Semua PoP]
    ?
    ?
[Scrubbing Center — Anti-DDoS 2+ Tbps Capacity]
(Akamai / Cloudflare / Alibaba Cloud Anti-DDoS)
    ?
    ?
[WAF — Web Application Firewall]
(ModSecurity / AWS WAF / Imperva)
    ?
    ?
[CDN Edge Layer — 20+ PoP Nasional]
    ?
    ?
[Origin Load Balancer — HAProxy / NGINX]
    ?
    ?
[Origin Server Cluster — 10 Node]
    ?
    ?
[ETL Engine — Private Network]
    ?
    ?
[Server Operasional — Private Cluster — TIDAK terekspos ke internet publik]
    ?
    ?
[Database Cluster PostgreSQL — 5 Node + 2 Standby]

Poin penting arsitektur ini:

Server operasional (tempat petugas TPS input data) berada di jaringan privat yang sama sekali tidak bisa diakses dari internet publik secara langsung
Koneksi dari aplikasi petugas TPS ke server operasional menggunakan VPN terenkripsi (WireGuard atau IPSec) dengan autentikasi berbasis sertifikat
Semua koneksi diaudit dan dilog secara immutable (tidak bisa dihapus atau diubah)
Rate limiting per IP di layer CDN: maksimum 100 request per menit per IP untuk mencegah scraping agresif

Layer 5: Aplikasi Mobile untuk Petugas TPS

Aplikasi yang digunakan petugas KPPS harus dirancang untuk kondisi koneksi yang tidak sempurna, mengingat infrastruktur internet di berbagai daerah Indonesia sangat bervariasi.

Fitur kritis:

Offline-first: Data bisa diinput meski tanpa koneksi internet. Disimpan lokal dulu, dikirim otomatis saat sinyal ada.
Conflict resolution: Jika ada dua input berbeda dari TPS yang sama (misalnya karena retry), sistem otomatis mendeteksi dan menandai untuk verifikasi manual.
Tanda tangan digital: Setiap submission data dari TPS ditandatangani secara digital menggunakan private key yang unik per perangkat. Ini membuat data tidak bisa dipalsukan di perjalanan.
Foto bukti: Upload foto formulir C-Hasil terintegrasi langsung dalam alur kerja, bukan sebagai langkah opsional.

Tech Stack Aplikasi:

React Native (cross-platform iOS dan Android)
SQLite untuk penyimpanan offline lokal
Background sync menggunakan WorkManager (Android) dan BGTaskScheduler (iOS)
End-to-end encryption untuk semua data yang dikirim

Estimasi Kapasitas yang Dibutuhkan

Dengan asumsi paling konservatif:

1% dari 190 juta pemilih = 1,9 juta pengguna aktif bersamaan
Rata-rata setiap pengguna melakukan 10 request dalam sesi 30 menit = ~630.000 request per menit pada peak
Dengan CDN yang benar dikonfigurasi dan cache hit ratio 99%, hanya ~6.300 request per menit yang mencapai origin server

Ini sangat manageable dengan infrastruktur yang dirancang di atas. Bahkan jika cache hit ratio turun ke 95% pun, origin server masih bisa menangani ~31.500 request per menit dengan 10 node yang tepat dikonfigurasi.

Masalahnya selama ini bukan pada kemampuan teknologi yang tidak ada — teknologinya sudah ada dan sudah terbukti. Masalahnya adalah pada kemauan untuk merancang sistem dengan benar sejak awal.

Tech Stack Rekomendasi Lengkap

Komponen	Teknologi
Aplikasi TPS (Mobile)	React Native + SQLite
Backend API Operasional	Go (Golang) atau Java Spring Boot
Database Utama	PostgreSQL 16 Cluster (Patroni)
Message Queue	Apache Kafka
ETL / Transformasi	Apache Spark + Airflow
Object Storage	MinIO (S3-compatible)
Cache Layer	Redis Cluster
CDN	Akamai + Cloudflare (dual CDN untuk failover)
Anti-DDoS	Akamai Prolexic + Cloudflare Magic Transit
Web Server Origin	Nginx
Load Balancer	HAProxy
Monitoring	Grafana + Prometheus + Loki
VPN Petugas	WireGuard
Autentikasi	OAuth2 + mTLS untuk petugas TPS
Container Orchestration	Kubernetes (K8s) dengan Helm
CI/CD	GitLab CI dengan blue-green deployment

Penutup: Masalah Ini Bisa Diselesaikan

Tidak ada hambatan teknologi yang membuat sistem data pemilu Indonesia tidak bisa dibangun dengan benar. Teknologinya ada, engineer-nya ada, dan referensi best practice-nya banyak — mulai dari sistem pemilu Estonia yang sudah berjalan solid selama dua dekade, hingga sistem distribusi data skala besar yang digunakan oleh platform fintech nasional dengan beban trafik yang jauh lebih tinggi.

Yang dibutuhkan adalah perencanaan yang jujur, anggaran yang dialokasikan dengan benar, dan — yang paling penting — komitmen bahwa transparansi data bukan ancaman, melainkan fondasi demokrasi itu sendiri.

Setiap suara yang diberikan warga adalah kepercayaan. Sistem yang memungkinkan warga memverifikasi suara mereka sendiri adalah bentuk penghormatan terhadap kepercayaan itu.

Aswandi adalah praktisi IT dengan spesialisasi di sistem informasi pemilu dan pemerintahan. Ia mengembangkan berbagai solusi digital untuk kebutuhan pemilu, termasuk software-pilkada.com — platform manajemen data dan pemenangan untuk Pilkada — dan data pemilu 2019 dan 2024 lengkap per tps beserta analisa di https://bigdata.pemilu.biz.id/

serta schoolmantic.com untuk pengelolaan data institusi. Blog ini merupakan bagian dari upaya berbagi pengetahuan di aswandi.or.id.

Referensi

Tirto.id — “Kenapa Website KPU Sempat Down di Hari Coblosan Pemilu 2024?” (14 Feb 2024)
Bisnis.com — “Website KPU Tak Bisa Diakses alias Down saat Pelaksanaan Pemilu 2024” (14 Feb 2024)
ANTARA News — “Web KPU sarana pengecekan hasil Pemilu 2024” (15 Feb 2024)
Detik.com — “KPU soal Website Eror di Hari Pencoblosan: Banyak Pihak yang Akses” (14 Feb 2024)
Liputan6.com — “Situs KPU Down Tak Bisa Diakses Sejak H-1 Pemilu 2024” (14 Feb 2024)
Suara.com — “Terungkap Alasan Situs KPU Sulit Diakses” (18 Apr 2019)
Detik.com — “Dua Penyebab Situs KPU Down dan Susah Diakses” (18 Apr 2019)
Liputan6.com — “Warganet Keluhkan Situs DPT Pemilu 2019 Tak Bisa Diakses” (15 Apr 2019)
Tempo.co — “Mengapa Grafik Data di Sirekap Raib” (Mar 2024)
Detik.com — “KPU Tak Lagi Tampilkan Grafik Data Suara Pemilu di Sirekap” (5 Mar 2024)
Investor.id — “Demi Transparansi ke Publik, KPU Tidak akan Tutup Akses Sirekap” (23 Feb 2024)