Menerapkan Rate Limiting Berdistribusi dengan Redis dan Go

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, sistem backend yang mendistribusikan layanan mikro (microservices) sering kali dihadapkan pada ancaman eksistensial berupa lonjakan trafik anomali, serangan brute-force, Distributed Denial of Service (DDoS), maupun penyalahgunaan API komersial (API scraping). Ketika sebuah aplikasi web berbasis Go melayani jutaan permintaan per detik di belakang reverse proxy seperti Nginx atau Caddy, ketiadaan sistem pembatasan laju (rate limiting) yang handal akan berakibat fatal pada stabilitas infrastruktur secara keseluruhan.

Bottleneck performa utama yang sering ditemukan di dunia nyata bukanlah pada kapasitas komputasi CPU dari bahasa Go yang memang dikenal sangat cepat, melainkan pada saturasi sumber daya downstream, seperti koneksi database relasional (MySQL/MariaDB), kehabisan memori connection pool, hingga resource exhaustion pada upstream services pihak ketiga. Sebelum penerapan sistem distributed rate limiting, arsitektur umumnya mengandalkan in-memory rate limiter pada masing-masing instance aplikasi. Pendekatan ini memiliki kelemahan mendasar: ketika aplikasi di-scaling secara horizontal menjadi 10 instance di balik Load Balancer, batas maksimal laju per klien akan meningkat secara linier sebesar jumlah instance, karena setiap instance menghitung kuota secara independen tanpa sinkronisasi global.

Sesudah penerapan Distributed Rate Limiting berbasis Redis, seluruh instance backend Go membaca dan menulis status kuota ke satu cluster penyimpanan terpusat yang sangat cepat dan konsisten. Hal ini memastikan bahwa batasan kuota per client IP atau API key bersifat absolut dan tidak dapat dieksploitasi melalui manipulasi distribusi trafik pada load balancer. Integrasi Redis dengan skrip Lua menjamin bahwa operasi pengecekan dan pengurangan token terjadi secara atomik tanpa race condition, bahkan di bawah konkurensi tingkat tinggi.