PPDB Sistem 3 Kota
Sistem PPDB multi-kota: instance terpisah per kota, capacity planning musim puncak, dan operasional yang tahan lonjakan saat gelombang buka serentak.
- Role
- Backend & DevOps Engineer (system owner)
- Tahun
- 2023
- Kota dilayani
- 3
- Pola deploy
- 1 app · N instance
- Musim puncak
- Gelombang serentak
- Peran
- IC + system owner
Ringkasan
Sistem Penerimaan Peserta Didik Baru (PPDB) diimplementasikan untuk 3 kota. Alur: pendaftaran online multi-jenjang, verifikasi dokumen, perangkingan otomatis, dashboard admin & monitoring operasional.
Infrastruktur: shared vs per kota?
Bukan satu server shared untuk semua kota. Pola yang dipakai:
| Layer | Keputusan | Alasan |
|---|---|---|
| Aplikasi | Codebase sama, deployment terpisah per kota | Isolasi data & jadwal; gagal di satu kota tidak menjatuhkan kota lain |
| Database | PostgreSQL terpisah (instance/schema isolation per kota) | Batas administratif & restore yang bersih |
| Edge | Reverse proxy (Nginx / NPM) per host atau host group | TLS, routing, rate limit per domain |
| Ops | Runbook & pipeline deploy yang seragam | Operasi multi-kota tetap konsisten tanpa multi-tenant “semua campur” |
Singkatnya: produk satu, runtime per kota — lebih aman untuk domain pemerintahan/pendidikan daripada multi-tenant single-DB yang shared keras.
Lonjakan traffic saat pendaftaran buka serentak
Musim PPDB: orang tua buka form hampir bersamaan di jam pengumuman. Yang disiapkan sebelum gelombang:
- Capacity planning — review index, slow query, pool koneksi DB, dan resource host sebelum H-hari; bukan “naikkan server saat sudah error”.
- Redis — cache baca berat + queue untuk pekerjaan non-kritis path (notifikasi, job sekunder) agar request HTTP tetap pendek.
- PostgreSQL — partial/index yang relevan perangkingan & filter status; hindari full-scan di path daftar/cek.
- Edge — rate limit & proteksi reverse proxy; jaga admin panel tidak kena beban publik yang sama.
- Operasional — checklist buka/tutup gelombang, monitoring error rate & latency, jalur rollback/restore backup.
Yang dihindari: single-point shared DB untuk 3 kota + “harap-harap aman” tanpa latihan musim puncak.
Fitur utama
- Pendaftaran online multi-jenjang
- Verifikasi dokumen digital
- Perangkingan otomatis
- Dashboard admin & monitoring
Tanggung jawab (level)
Individual contributor · system owner — merancang backend, mengoperasikan infra, dan menanggung reliabilitas di musim puncak. Bukan pure feature-dev; bukan manajer tim.
- Backend Laravel + alur bisnis PPDB
- Optimasi PostgreSQL & Redis untuk beban puncak
- Hardening server Linux/Nginx, deploy, backup
- Runbook agar tim/ops lokal bisa ikut menjaga saat musim
Metrik yang jujur (bukan vanity)
Tidak menampilkan “99.x% uptime” atau “X juta user” tanpa audit publik. Yang bisa dibuktikan dari kerja nyata:
- 3 kota dilayani dengan pola instance terpisah
- Musim puncak berulang — sistem didesain untuk gelombang, bukan demo sepi
- Ownership end-to-end — dari kode sampai server hidup
Angka traffic internal klien bersifat sensitif; di wawancara teknis bisa dibahas pola beban & keputusan arsitektur secara detail.
Lessons Learned
- Multi-kota ≠ “satu app gede shared”: isolasi runtime mengurangi blast radius
- Musim PPDB = capacity planning + monitoring, bukan hanya fitur form
- Partial index & query path kritis menentukan throughput di jam buka
- Runbook & handover setara pentingnya dengan fitur baru