Beberapa kali Server Direktorat Jenderal Pajak kembali mengalami downtime. Bukan untuk pertama kali. Sejak diluncurkan awal tahun ini, sistem Coretax—platform modernisasi perpajakan terbesar dalam sejarah Indonesia—sudah berkali-kali mengalami pemeliharaan mendadak. Di April, sistem mati 18 jam. Di Juni, lagi. Juli, lagi.
Di ruang kontrol pusat data, layar menampilkan grafik merah menyala: ribuan permintaan per detik menghantam endpoint yang sama. Bagi wajib pajak, ini hanya klik tombol "Lapor SPT". Bagi sistem, ini tsunami digital.
86,7 Juta Wajib Pajak, Satu Pintu Masuk
Bayangkan ini: pada akhir 2024, Indonesia mencatat 86,7 juta wajib pajak terdaftar—naik 17,23% dari tahun sebelumnya. Dari jumlah itu, 19,78 juta diwajibkan melaporkan SPT Tahunan. Dan ketika tenggat waktu mendekat—seperti 31 Maret untuk wajib pajak orang pribadi—jutaan orang serentak membuka portal yang sama.
Data DJP mencatat hingga 1 April 2025, 12,34 juta SPT Tahunan sudah diterima. Itu berarti rata-rata lebih dari 400.000 SPT masuk per hari di minggu terakhir Maret. Dalam hitungan kasar, jika diasumsikan 8 jam kerja per hari, itu sekitar 14.000 transaksi per menit. Dan setiap transaksi tidak sesederhana satu klik—ada login, pengisian formulir, unggah dokumen, submit, hingga notifikasi.
Tanpa mekanisme pembatas yang cermat, server bisa kolaps. Dan ketika sistem publik kolaps, konsekuensinya bukan sekadar keluhan di media sosial. Ini soal macetnya roda administrasi negara.
Anatomi Rate Limiter: Polisi Lalu Lintas Digital
Di sinilah rate limiter masuk. Dalam arsitektur IT modern, rate limiter bekerja seperti polisi lalu lintas—mengatur siapa boleh lewat, berapa banyak, dan seberapa cepat. Ia adalah gerbang tol digital yang menjaga agar tidak semua mobil masuk sekaligus.
Mekanismenya didasarkan pada dua algoritma utama: Token Bucket dan Leaky Bucket. Keduanya punya filosofi berbeda, tapi tujuan sama: menjaga stabilitas sistem di tengah lonjakan trafik.
Token Bucket: Ember dengan Koin
Bayangkan sebuah ember berisi koin (token). Setiap kali pengguna ingin mengirim permintaan ke server, mereka harus "membayar" dengan satu token dari ember. Jika token tersedia, permintaan diproses. Jika tidak, permintaan ditolak atau ditunda.
Yang menarik: ember ini terus diisi ulang secara otomatis. Misalnya, setiap detik ditambah 10 token baru, dengan kapasitas maksimum 100 token. Ini berarti sistem bisa menangani burst traffic—lonjakan mendadak—selama masih ada token di ember. Tapi jika semua token habis, pengguna harus menunggu hingga ember terisi kembali.
Token Bucket memproses permintaan dengan jumlah token yang tersedia secara dinamis, memungkinkan sistem menangani burst traffic sementara selama token masih ada di dalam ember. Inilah kenapa algoritma ini populer di API Gateway seperti NGINX, Kong, atau AWS API Gateway—mereka butuh fleksibilitas untuk menangani pola trafik yang tidak menentu.
Contoh konkret: Twitter membatasi akun gratis hingga 500 tweet per hari. Itu adalah implementasi Token Bucket. Anda bisa mem-posting 50 tweet sekaligus dalam satu menit (burst), tapi setelah itu harus menunggu token terisi kembali.
Leaky Bucket: Ember yang Bocor
Algoritma kedua, Leaky Bucket, bekerja berbeda. Bayangkan permintaan masuk seperti air yang dituang ke dalam ember. Permintaan diproses (bocor keluar) dengan kecepatan konstan, seperti air yang menetes dari lubang. Jika permintaan datang terlalu cepat, ember meluap, dan permintaan berlebih diabaikan.
Bedanya dengan Token Bucket: Leaky Bucket memproses permintaan dengan kecepatan tetap, bukan berdasarkan ketersediaan token. Ini membuatnya lebih stabil dan prediktabel, tapi kurang fleksibel untuk burst traffic.
Algoritma Leaky Bucket dapat memproses permintaan secara robust karena hanya memproses permintaan dalam jendela waktu yang tetap. Namun, ia memiliki masalah: permintaan yang diproses mungkin bukan yang terbaru. Seperti antrean roller coaster di taman bermain—Anda harus menunggu giliran, bahkan jika antrian sangat panjang.
Contoh konkret: Router jaringan menggunakan Leaky Bucket untuk mengatur aliran paket data. Paket masuk dengan kecepatan bervariasi, tapi diproses dengan kecepatan konstan untuk mencegah kongesti.
Token vs Leaky: Kapan Pakai yang Mana?
Token Bucket memberikan kontrol granular dengan parameter MAX_CAPACITY dan REFILL_RATE, memungkinkan burst traffic singkat melebihi REFILL_RATE selama token masih tersedia. Sementara Leaky Bucket menghasilkan output konstan yang ditentukan oleh LEAK_RATE, memberikan perilaku prediktabel yang memudahkan pemeliharaan.
Dalam praktik, Sistem pemerintah cenderung menggunakan Token Bucket karena fleksibilitasnya. Ketika jutaan wajib pajak mengakses sistem di hari terakhir pelaporan, burst traffic tidak bisa dihindari. Token Bucket memungkinkan sistem menangani lonjakan singkat tanpa langsung menolak semua permintaan.
Tapi untuk aplikasi yang butuh output stabil—seperti streaming video atau processing antrian transaksi—Leaky Bucket lebih cocok.
Implementasi di Dunia Nyata: Dari Startup hingga Negara
Rate limiter bukan teknologi eksotis. Ia adalah standar industri yang digunakan di mana-mana.
Google API membatasi permintaan per detik dan per hari. Jika Anda menggunakan Google Maps API versi gratis, Anda hanya bisa melakukan 40.000 permintaan per bulan. Melebihi itu? Sistem mengembalikan error HTTP 429: Too Many Requests.
GitHub API membatasi 5.000 permintaan per jam untuk pengguna yang sudah login. Setiap response header menyertakan informasi: X-RateLimit-Remaining: 4999, memberitahu berapa permintaan yang masih bisa dilakukan.
Gojek, Tokopedia, Shopee—mereka semua menggunakan rate limiter untuk bertahan saat flash sale. Ketika kampanye 11.11 atau Harbolnas, lonjakan pengguna bisa meledak ribuan kali lipat dalam satu menit. Tanpa rate limiter, server mereka akan kolaps dalam hitungan detik.
Rate Limiter di Layer Gateway: Benteng Pertahanan Pertama
Dalam arsitektur Coretax, rate limiter bisa diterapkan di API Gateway—pintu masuk utama sebelum permintaan mencapai server aplikasi atau database. Ini adalah benteng pertahanan pertama.
Ketika pengguna klik "Login" di portal Coretax, permintaan tidak langsung masuk ke database. Ia harus melewati beberapa lapisan:
- Load Balancer — Membagi trafik ke beberapa server
- API Gateway — Di sinilah rate limiter bekerja
- Application Server — Memproses logika bisnis
- Database — Menyimpan dan mengambil data
Jika rate limiter tidak ada, semua permintaan—termasuk yang berlebihan—akan langsung menghantam application server dan database. Dalam hitungan menit, sistem bisa crash.
Dengan rate limiter, sistem bisa membatasi, misalnya:
- 100 permintaan per menit per pengguna
- 1.000 permintaan per menit per IP address
- 10.000 permintaan per menit untuk seluruh sistem
Jika batas terlampaui, API Gateway mengembalikan response: HTTP 429 - Too Many Requests. Retry-After: 60 seconds.
Pengguna mungkin harus menunggu sebentar, tapi setidaknya sistem tidak kolaps total.
Dari Bug hingga Latensi: Perjuangan Menstabilkan Sistem
Per Mei 2025, mantan Dirjen Pajak Suryo Utomo menyebutkan bahwa DJP masih memperbaiki bug di 18 proses bisnis—turun dari 21 sebelumnya. Target penyelesaian: akhir Juli 2025. Sementara migrasi data dari sistem lama (DJP Online) ke Coretax ditargetkan selesai Desember 2025.
Tantangannya bukan sekadar teknis. Ini soal ekspektasi. Wajib pajak menginginkan sistem yang cepat dan stabil. Fiskus membutuhkan data real-time untuk pengawasan. Dan DJP harus memastikan bahwa ketika jutaan orang mengakses sistem secara bersamaan—seperti saat tenggat waktu pelaporan SPT—server tidak ambruk.
Dalam implementasi modern, rate limiter tidak hanya membatasi jumlah permintaan, tapi juga memberi sinyal ke sistem lain. Misalnya:
- Jika trafik melonjak di atas threshold tertentu, auto-scaling akan menambah server secara otomatis
- Jika ada pengguna yang mencoba melakukan brute force attack (menebak password berkali-kali), rate limiter akan memblokir IP tersebut
- Jika ada aplikasi pihak ketiga yang membanjiri API dengan permintaan berlebihan, rate limiter akan membatasi akses mereka
Ini bukan hanya soal mencegah crash—ini soal keamanan, efisiensi, dan pengalaman pengguna.
Pelajaran dari Flash Sale hingga Pemilu
Indonesia sebenarnya tidak asing dengan lonjakan trafik ekstrem. Platform e-commerce seperti Tokopedia dan Shopee rutin menghadapi jutaan pengguna serentak saat kampanye 11.11 atau Harbolnas. Mereka bertahan bukan karena server raksasa, tapi karena arsitektur yang cermat—termasuk rate limiting yang ketat.
Begitu pula dengan sistem pemerintah lain. Online Single Submission (OSS) untuk perizinan usaha, atau sistem pendaftaran CPNS, juga menghadapi pola serupa: ribuan pengguna mengakses sistem dalam waktu singkat. Tanpa pembatas yang tepat, sistem bisa lumpuh dalam hitungan menit.
Pengalaman global menunjukkan hal yang sama. Saat pemilu di beberapa negara, server registrasi pemilih sering kolaps karena lonjakan trafik. Solusinya bukan menambah server sebanyak mungkin, tapi mengatur arus dengan cerdas—dan itulah fungsi rate limiter.
Paradoks yang Indah: Melambat untuk Tetap Cepat
Ada ironi dalam arsitektur IT modern: yang menjaga sistem tetap cepat justru alat yang memperlambatnya sedikit. Rate limiter bukan penghambat—ia adalah pengatur ritme. Ia memastikan bahwa sistem tidak kewalahan, sumber daya dibagi adil, dan tidak ada satu pengguna yang membanjiri server sendirian.
Rate limiter berguna untuk aplikasi yang memerlukan kontrol lebih presisi atas pembatasan rate dan dapat menanggung overhead memori tambahan. Bermanfaat untuk aplikasi yang perlu memproses permintaan dengan kecepatan konsisten, seperti network traffic shaping atau mengontrol operasi write ke disk.
Di dunia yang terobsesi dengan kecepatan, rate limiter ini relevan: kadang, untuk menjaga kelancaran bersama, kita memang harus rela menunggu sebentar.
Di balik setiap halaman login yang "sedikit lebih lama", mungkin ada mekanisme perlindungan yang sedang bekerja. Rate limiter memastikan bahwa meskipun jutaan orang mengakses sistem yang sama, semuanya tetap mendapatkan giliran.
Top comments (0)