DEV Community: Mohamad Hasan

Ketika 14.000 Transaksi Membanjiri Server Per Menit: Bagaimana Rate Limiter Cegah Crash

Mohamad Hasan — Sat, 25 Oct 2025 08:00:40 +0000

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.

Ketika Golang Dipilih untuk Kirim Pesan Yang Sibuk

Mohamad Hasan — Thu, 08 May 2025 16:20:23 +0000

Bayangkan sebuah kota metropolitan di zaman belum ada telepon dan internet. Ribuan surat datang setiap hari ke kantor pos pusat, dan harus dibagikan ke rumah-rumah atau kantor di seluruh penjuru kota. Jika hanya satu tukang pos yang bertugas, tentu surat akan menumpuk, pengiriman jadi lambat, dan banyak pesan penting yang terlambat sampai. Tapi bagaimana jika ada puluhan, bahkan ratusan tukang pos yang bisa bekerja bersama, saling membantu, dan semuanya bisa berkoordinasi dengan baik? Inilah gambaran sederhana mengapa sistem pengiriman pesan yang canggih membutuhkan teknologi yang tepat.

Mengapa Golang? Karena Golang seperti pasukan tukang pos super cepat yang bisa bergerak serempak tanpa saling tabrakan. Dalam dunia komputer, ini disebut concurrency—kemampuan melakukan banyak hal sekaligus. Golang punya alat khusus bernama goroutine, seperti tukang pos kecil yang bisa diutus kapan saja untuk mengantarkan surat. Tidak hanya itu, mereka bisa saling mengirim kabar lewat channels, semacam kode-kode atau pesan singkat agar tidak ada yang salah paham atau tersesat di jalan.

1. Concurrency dengan Goroutines dan Channels

Ketika kota harus mengirim banyak surat ke berbagai penjuru sekaligus, satu-satunya cara agar pesan tidak menumpuk adalah dengan membagi tugas ke banyak tukang pos. Di Golang, setiap "tukang pos" ini disebut goroutine. Mereka bisa diaktifkan kapan saja, jumlahnya bisa sangat banyak, dan mereka tidak saling mengganggu.

Misalnya, saat kantor pos menerima surat, Golang bisa langsung mengutus goroutine untuk mengantarkannya tanpa harus menunggu tugas lain selesai. Ini seperti mengirim surat ke banyak alamat sekaligus, bukan satu per satu. Dengan channel, setiap goroutine bisa memberi kabar, “Surat sudah sampai!” atau “Ada masalah di jalan!” sehingga koordinasi tetap terjaga.

Lihat dokumentasi goroutine

// MessageProcessor menangani pesan secara concurrent
type MessageProcessor struct {
    incomingMessages chan Message
    workers          int
}

func (mp *MessageProcessor) Start() {
    // Jalankan multiple workers
    for i := 0; i < mp.workers; i++ {
        go mp.processMessages()
    }
}

func (mp *MessageProcessor) processMessages() {
    for msg := range mp.incomingMessages {
        // Proses setiap pesan dalam goroutine terpisah
        go mp.handleMessage(msg)
    }
}

type MessageQueue struct {
    messages    chan Message
    errors      chan error
    shutdown    chan struct{}
}

func (mq *MessageQueue) Listen() {
    for {
        select {
        case msg := <-mq.messages:
            // Proses pesan baru
            log.Printf("Processing message ID: %s", msg.ID)
        case err := <-mq.errors:
            // Tangani error
            log.Printf("Error processing message: %v", err)
        case <-mq.shutdown:
            // Terima sinyal shutdown
            log.Println("Shutting down message processor")
            return
        }
    }
}

Tapi, bagaimana jika ada dua tukang pos yang ingin menghitung berapa banyak surat yang sudah dikirim? Kalau tidak hati-hati, catatan bisa jadi berantakan. Di sinilah atomic operation berperan, memastikan setiap penambahan atau pengurangan dilakukan dengan rapi, tanpa rebutan.

Lihat dokumentasi sync/atomic

type MessageStats struct {
    processed atomic.Int64
    failed    atomic.Int64
}

func (ms *MessageStats) RecordSuccess() {
    ms.processed.Add(1)
}

func (ms *MessageStats) RecordFailure() {
    ms.failed.Add(1)
}

func (ms *MessageStats) GetStats() (processed, failed int64) {
    return ms.processed.Load(), ms.failed.Load()
}

2. Message Queue dengan RabbitMQ

Sekarang bayangkan ada lumbung surat besar di tengah kota. Semua surat dari luar kota ditaruh di sana dulu, lalu tukang pos mengambil satu per satu sesuai rute dan giliran. RabbitMQ adalah lumbung surat digital yang memastikan tidak ada surat yang hilang, dan setiap pesan diproses dengan urutan yang benar.

Dengan bantuan goroutine, surat-surat ini bisa diambil dan diantarkan secara bersamaan, pekerjaan jadi jauh lebih cepat. Setiap pesan yang masuk ke antrian akan diantar oleh tukang pos (worker) yang berjalan dalam goroutine terpisah, memastikan tidak ada penumpukan di satu titik.

type Consumer struct {
    queue    string
    messages <-chan amqp.Delivery
    done     chan struct{}
}

func (c *Consumer) Start(ctx context.Context) error {
    for i := 0; i < c.workerCount; i++ {
        go func() {
            for {
                select {
                case msg := <-c.messages:
                    if err := c.processMessage(msg); err != nil {
                        msg.Nack(false, true) // Kirim kembali ke queue
                        continue
                    }
                    msg.Ack(false)
                case <-ctx.Done():
                    return
                }
            }
        }()
    }
    return nil
}

Manajemen perjalanan tukang pos menjadi sangat penting. Sistem harus bisa menambah, menghentikan, dan memantau setiap tukang pos secara dinamis. Heartbeat dan error channel digunakan untuk memastikan setiap tukang pos tetap aktif dan bisa digantikan jika ada yang kelelahan atau tersesat.

type ConsumerHealth struct {
    lastHeartbeat atomic.Value
    status        atomic.Value
    done          chan struct{}
}

func (h *ConsumerHealth) Monitor(interval time.Duration) {
    ticker := time.NewTicker(interval)
    go func() {
        for {
            select {
            case <-ticker.C:
                h.updateHealth()
                if !h.isHealthy() {
                    h.status.Store("unhealthy")
                    h.reconnect()
                }
            case <-h.done:
                ticker.Stop()
                return
            }
        }
    }()
}

3. Graceful Shutdown

Sistem juga harus tahu kapan harus berhenti bekerja. Ketika hari mulai gelap dan kota harus beristirahat, semua tukang pos harus memastikan tidak ada surat yang tertinggal sebelum pulang. Inilah yang disebut graceful shutdown. Dengan WaitGroup, Golang memastikan semua tugas benar-benar selesai sebelum sistem dimatikan. Tidak ada pesan yang terlewat, tidak ada pengiriman yang ditinggalkan begitu saja.

Lihat dokumentasi context, sync.WaitGroup, dan goroutine

type MessageServer struct {
    consumers map[string]*Consumer
    wg        sync.WaitGroup
}

func (s *MessageServer) Shutdown(ctx context.Context) error {
    // Kirim sinyal shutdown ke semua consumer
    for id, consumer := range s.consumers {
        s.wg.Add(1)
        go func(id string, c *Consumer) {
            defer s.wg.Done()
            if err := c.Shutdown(ctx); err != nil {
                log.Printf("Error shutting down consumer %s: %v", id, err)
            }
        }(id, consumer)
    }

    // Tunggu semua consumer selesai atau context timeout
    done := make(chan struct{})
    go func() {
        s.wg.Wait()
        close(done)
    }()

    select {
    case <-done:
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}

Dalam implementasi nyata, graceful shutdown diintegrasikan ke seluruh komponen. Shutdown manager akan menangkap sinyal sistem (seperti SIGINT atau SIGTERM), membatalkan context, menutup channel, dan menunggu semua proses selesai dengan WaitGroup. Hasilnya, sistem dapat berhenti dengan mulus tanpa kehilangan data atau meninggalkan proses zombie.

Penutup: Apa Pelajaran Besarnya?

Mengapa semua ini penting? Karena dalam dunia nyata, sistem seperti ini harus bisa diandalkan. Tidak boleh ada pesan yang hilang, tidak boleh ada pengiriman yang macet, dan semuanya harus bisa berjalan cepat tanpa saling mengganggu. Golang menyediakan semua alat itu secara sederhana, efisien, dan mudah dipahami.

Pelajaran terbesar dari perjalanan ini sederhana: teknologi terbaik adalah yang mampu membuat hal rumit menjadi mudah, dan yang mampu bekerja sama seperti tim yang solid—bahkan jika tim itu terdiri dari jutaan “petugas surat” digital yang bekerja tanpa henti di balik layar.