Dalam pengembangan sistem backend, performa bukanlah satu-satunya faktor yang menentukan kualitas sebuah aplikasi. Sebuah REST API yang cepat tetap bisa tumbang jika tidak memiliki mekanisme perlindungan terhadap lonjakan trafik yang tidak terkendali.
Beberapa waktu terakhir saya melakukan serangkaian optimasi pada backend yang dibangun menggunakan Brook Framework dan ZeosLib. Setelah berhasil meningkatkan efisiensi akses database melalui Connection Pool serta menghemat bandwidth menggunakan Deflate Compression, saya mulai fokus pada lapisan keamanan yang sering diabaikan oleh banyak developer, yaitu API Rate Limiting.
Tujuannya sederhana: mencegah satu klien membanjiri server dengan request berlebihan dalam waktu singkat.
Mengapa Rate Limiting Penting?
Bayangkan sebuah aplikasi klinik atau SIMRS yang melayani ratusan pengguna secara bersamaan. Kemudian terjadi salah satu kondisi berikut:
Bug pada aplikasi frontend yang menyebabkan request berjalan dalam loop tanpa henti.
Script otomatis yang mencoba melakukan brute force login.
Bot yang mengirim ribuan request dalam hitungan detik.
Serangan DDOS sederhana yang menargetkan endpoint tertentu.
Tanpa perlindungan, server akan menerima seluruh request tersebut, memprosesnya satu per satu, membuka koneksi database, dan akhirnya menghabiskan sumber daya CPU maupun memori.
Akibatnya:
Penggunaan CPU melonjak drastis.
Koneksi database penuh.
Query menjadi lambat.
Pengguna normal ikut terdampak.
Sistem utama berpotensi mengalami hang atau crash.
Di sinilah Rate Limiting berperan sebagai penjaga gerbang pertama.
Apa Itu API Rate Limiting?
Secara sederhana, Rate Limiting adalah mekanisme pembatasan jumlah request yang dapat dilakukan oleh satu pengguna atau alamat IP dalam rentang waktu tertentu.
Analogi yang mudah dipahami adalah pintu putar otomatis di stasiun atau rumah sakit.
Setiap orang boleh masuk, tetapi ada batas kecepatan dan jumlah akses yang diperbolehkan. Ketika seseorang mencoba masuk secara berlebihan, sistem akan menolak akses tersebut secara otomatis.
Dalam dunia HTTP, respons penolakan ini biasanya menggunakan status:
429 Too Many Requests
Keuntungan terbesar dari pendekatan ini adalah request berlebihan dihentikan sebelum menyentuh database. Dengan demikian beban server tetap rendah meskipun terjadi lonjakan trafik.
Arsitektur Implementasi di Brook Framework
Pada eksperimen ini saya menerapkan kebijakan sederhana:
Maksimal 10 request per menit untuk setiap alamat IP.
Karena proses pengecekan dilakukan di memori, respons dapat diberikan sangat cepat tanpa perlu melakukan query ke database.
1. Menyimpan Histori IP di Memori
Untuk mencatat aktivitas setiap IP, saya menggunakan TStringList yang ditempatkan pada bagian private form utama.
private
FIPTracker: TStringList;
Setiap IP akan menyimpan informasi:
JumlahHit|WaktuReset
Contoh:
192.168.1.10=7|2026-06-11 15:30:00
Artinya:
IP telah melakukan 7 request.
Counter akan di-reset pada waktu yang ditentukan.
Catatan Penting
Saat melakukan pengujian, saya menemukan bahwa:
FIPTracker.Sorted := True;
tidak cocok digunakan untuk skenario ini.
Ketika nilai string diubah secara dinamis pada lingkungan multithread, Lazarus dapat menghasilkan exception:
EStringListError:
Operation not allowed on sorted list
Karena itu saya menggunakan:
FIPTracker.Sorted := False;
agar proses update data lebih aman.
Middleware Pengecekan Rate Limit
Setiap request yang masuk akan melalui fungsi berikut sebelum diproses lebih lanjut.
Jika IP belum pernah tercatat, maka akan dibuat entri baru.
Jika sudah tercatat, sistem akan memeriksa:
Apakah waktu reset telah lewat.
Berapa jumlah request yang telah dilakukan.
Apakah jumlah request melebihi batas yang ditentukan.
function TFormUtama.CheckRateLimit(AIP: string): Boolean;
var
vIndex: Integer;
vHitCount: Integer;
vCurrentTime: TDateTime;
vLastResetTime: TDateTime;
vDataStr, vHitStr, vTimeStr: string;
vPosPemisah: Integer;
begin
Result := True;
vCurrentTime := Now;
vIndex := FIPTracker.IndexOfName(AIP);
if vIndex = -1 then
begin
FIPTracker.Add(AIP + '=1|' +
DateTimeToStr(vCurrentTime + (1 / 1440)));
end
else
begin
vDataStr := FIPTracker.ValueFromIndex[vIndex];
vPosPemisah := Pos('|', vDataStr);
vHitStr := Copy(vDataStr, 1, vPosPemisah - 1);
vTimeStr := Copy(vDataStr, vPosPemisah + 1,
Length(vDataStr));
vHitCount := StrToIntDef(vHitStr, 0);
vLastResetTime := StrToDateTimeDef(vTimeStr,
vCurrentTime);
if vCurrentTime > vLastResetTime then
begin
FIPTracker.Strings[vIndex] :=
AIP + '=1|' +
DateTimeToStr(vCurrentTime + (1 / 1440));
end
else
begin
Inc(vHitCount);
if vHitCount > 10 then
Result := False;
FIPTracker.Strings[vIndex] :=
AIP + '=' +
IntToStr(vHitCount) + '|' +
DateTimeToStr(vLastResetTime);
end;
end;
end;
Jika fungsi mengembalikan nilai False, server langsung memberikan respons HTTP 429 tanpa melanjutkan ke proses bisnis maupun database.
Membuktikan dengan Load Testing
Sebagai developer sekaligus IT Manager, saya lebih percaya pada angka dibanding asumsi.
Karena itu saya melakukan pengujian menggunakan ApacheBench (ab.exe), salah satu tool benchmark HTTP yang ringan dan sudah lama digunakan untuk menguji performa web server.
Pengujian dilakukan dengan mengirim 15 request berturut-turut ke endpoint:
/barang_limit
menggunakan perintah:
ab.exe -n 15 -c 1 -H "Authorization: ismail" ^
http://localhost:8888/barang_limit
Hasil Pengujian
Server Hostname: localhost
Server Port: 8888
Document Path: /barang_limit
Document Length: 89 bytes
Complete requests: 15
Failed requests: 0
Non-2xx responses: 15
Time taken for tests: 0.003 seconds
Requests per second: 4810.78 [#/sec]
Processing Time: 0 ms
Analisis Hasil
1. Rate Limiter Berjalan Sesuai Harapan
Nilai:
Non-2xx responses: 15
menunjukkan bahwa seluruh request berhasil dikenali sebagai trafik yang harus dibatasi.
Server memberikan respons penolakan tanpa mengalami error.
2. Waktu Pemrosesan Nyaris Nol
Bagian yang paling menarik adalah:
Processing Time: 0 ms
Karena pengecekan dilakukan langsung di memori RAM, server tidak perlu:
Membuka koneksi database.
Menjalankan query SQL.
Mengambil data dari disk.
Inilah salah satu keunggulan aplikasi native yang dibangun menggunakan Free Pascal dan Lazarus.
3. Throughput Tetap Tinggi
Meskipun sedang menolak request, backend masih mampu menghasilkan:
4810 Request per Detik
Angka ini menunjukkan bahwa proses validasi sangat ringan dan hampir tidak memberikan beban tambahan pada server.
Catatan untuk Lingkungan Produksi
Implementasi menggunakan TStringList sangat cocok untuk:
Belajar konsep Rate Limiting.
Proyek skala kecil hingga menengah.
REST API internal perusahaan.
Sistem klinik dan UMKM.
Namun untuk lingkungan enterprise berskala besar, saya menyarankan menggunakan:
Redis
Memcached
Shared Memory
Distributed Cache
agar data rate limit dapat dibagikan antar banyak instance server.
Penutup
Membangun REST API yang cepat memang penting. Namun membangun REST API yang cepat, hemat resource, dan aman adalah standar yang seharusnya diterapkan sejak awal pengembangan.
Dari berbagai eksperimen yang saya lakukan menggunakan Brook Framework dan ZeosLib, kombinasi berikut memberikan hasil yang sangat memuaskan:
Zeos Connection Pool untuk efisiensi database.
Deflate Compression untuk penghematan bandwidth.
API Rate Limiting untuk perlindungan terhadap lonjakan trafik.
Ketiga komponen tersebut membentuk fondasi backend yang ringan, cepat, dan cukup tangguh untuk digunakan pada berbagai aplikasi bisnis seperti sistem klinik, inventory, hingga SIMRS.
Bagaimana dengan backend yang Anda kelola saat ini? Apakah sudah memiliki mekanisme pembatasan request?
Silakan berbagi pengalaman atau pendapat Anda di kolom komentar.
0 komentar