Pernah nggak sih kamu bayangin kalau API yang kamu bikin itu ibarat pintu masuk ke sebuah toko yang lagi viral banget? Wah, kalau pelanggan datangnya satu-satu dan tertib sih semuanya pasti aman-aman aja! Tapi, gimana kalau tiba-tiba ada ribuan orang yang coba mendobrak masuk barengan lewat satu pintu yang sempit itu? Wah, pasti bakal kacau banget kan! Rak-rak bisa roboh, dan pelanggan yang beneran mau belanja malah nggak bisa masuk gara-gara macet total. Nah, inilah alasan kenapa API kamu butuh “satpam” yang kuat!
Di dunia koding, satpam ini namanya Rate Limiting. Singkatnya sih, ini cara kita buat membatasi berapa kali seorang pengguna boleh “ngetok pintu” alias kirim permintaan ke server dalam waktu tertentu. Kalau nggak ada pagar ini, sistem kamu bakal gampang banget dijebol lho! Entah itu sengaja diserang atau cuma gara-gara ada salah koding di sisi pengguna. Jadi, buat kalian para pengembang backend, belajar ini tuh wajib banget supaya server kamu nggak “ngos-ngosan” pas lagi banyak trafik!
Nah, di artikel kali ini, kita bakal kupas tuntas kenapa sih Rate Limiting itu penting banget dan gimana cara gampang pasangnya di aplikasi kamu pakai framework favorit kita: FastAPI. Siap-siap ya, kita bakal bikin API kamu makin tangguh menghadapi serbuan trafik masa kini!
Bahaya Lho Kalau API Dibiarkan Tanpa “Pagar”!
Masalah paling utama kalau API kamu dibiarkan terbuka bebas tanpa batas itu adalah serangan Denial of Service (DoS). Di sini, ada orang jahat yang sengaja kirim jutaan permintaan sampah cuma buat bikin server kamu pusing! Kalau nggak ada pembatas, server bakal capek sendiri karena harus ngurusin semua permintaan sampah itu sampai energinya habis. Akhirnya apa? Pengguna yang beneran butuh layanan kamu malah nggak bisa akses sama sekali. Duh, bisa rugi gede kan kalau sampai begini!
Selain itu, ada juga bahaya serangan Brute Force. Coba deh bayangin kalau bagian login kamu nggak ada batasannya sama sekali. Orang jahat bisa pakai robot buat tebak-tebak kata sandi ribuan kali tiap detiknya! Tanpa Rate Limiting, sistem kamu seolah-olah kasih waktu tanpa batas buat mereka sampai berhasil jebol. Ngeri banget kan? Data pelanggan kamu bisa jadi taruhannya cuma gara-gara pintunya nggak dikasih kunci pengaman yang bener.
Masalah lainnya itu soal biaya dan performa, nih. Sekarang banyak banget API yang pakai layanan pihak ketiga yang berbayar, atau butuh proses berat di server. Kalau ada satu pengguna yang “maruk” dan panggil API kamu terus-terusan, tagihan server kamu bisa bengkak atau server jadi lemot buat pengguna lain! Kita sering sebut ini Noisy Neighbor Effect—kayak punya tetangga berisik yang bikin satu komplek jadi nggak nyaman. Kita nggak mau kan kalau cuma gara-gara satu orang, pengguna lainnya jadi keganggu?
Cara Cerdas Pasang “Filter” Trafik
Nah, solusinya ya kita harus pasang strategi Rate Limiting yang pinter! Ada beberapa cara atau algoritma yang biasa dipakai. Yang paling simpel namanya Fixed Window Counter. Intinya sih kita batasi jumlah permintaan dalam satu kotak waktu, misal 100 kali tiap menit. Tapi ada kelemahannya nih! Pengguna bisa aja kirim 100 permintaan di detik-detik terakhir menit pertama, terus kirim lagi 100 di detik pertama menit kedua. Hasilnya? Server malah dapet 200 permintaan sekaligus dalam sekejap! Wah, kaget juga servernya!
Biar lebih halus, banyak orang pakai algoritma Sliding Window. Cara ini lebih akurat karena hitungannya ngikutin waktu yang terus jalan. Tapi kalau kamu mau yang paling efisien soal memori, cobain deh algoritma Token Bucket. Bayangin ada sebuah ember yang diisi koin setiap detiknya. Tiap kali mau panggil API, pengguna harus ambil satu koin. Kalau koinnya habis, ya harus nunggu embernya keisi lagi. Cara ini asyik banget karena masih bolehin ada sedikit lonjakan (burst) trafik selama koin di ember masih ada!
Terus, pasangnya di mana ya? Kamu bisa pasang di bagian depan banget (API Gateway) kayak pakai Nginx. Tapi kalau mau yang lebih fleksibel dan bisa diatur per-endpoint, pasang aja di level aplikasi pakai bantuan Redis. Kenapa Redis? Karena dia kerjanya di dalam memori, jadi proses ngecek jatah koin tadi itu cepet banget, cuma hitungan milidetik aja! Jadi nggak bakal bikin server kamu tambah lemot deh!
Ayo Kita Coba!
Yuk, sekarang kita langsung praktek bikin “satpam” simpel buat aplikasi FastAPI kita! Kita bakal pakai Redis supaya sistemnya tetap kompak meskipun servernya ada banyak.
Pertama-tama, instal dulu bahan-bahannya lewat terminal ya:
pip install fastapi uvicorn redis
Setelah itu, ini kodenya (santai aja, pelan-pelan bacanya ya!):
from fastapi import FastAPI, Request, HTTPExceptionimport redis.asyncio as aioredisfrom contextlib import asynccontextmanager# Kita siapkan koneksi Redis-nya dulu ya!# Pakai Lifespan supaya koneksi rapi pas aplikasi nyala & matiredis_client = None@asynccontextmanagerasync def lifespan(app: FastAPI): global redis_client # Ganti 'localhost' kalau Redis kamu ada di tempat lain ya! redis_client = aioredis.from_url("redis://localhost:6379", encoding="utf-8", decode_responses=True) print("Wah, Redis sudah siap membantu menjaga pintu!") yield await redis_client.close()app = FastAPI(lifespan=lifespan)# Ini dia logika "satpam" kita!async def satpam_api(request: Request): # Kita kenali pengguna lewat alamat IP-nya ya ip = request.client.host key = f"jatah-api:{ip}" # Kita set: Boleh 10 kali panggil tiap 60 detik limit = 10 window_waktu = 60 # dalam detik try: # Tambah hitungan di Redis setiap ada yang panggil jumlah_sekarang = await redis_client.incr(key) if jumlah_sekarang == 1: # Kalau baru pertama kali panggil, kita kasih timer 1 menit await redis_client.expire(key, window_waktu) # Kalau sudah lewat batas, kita suruh nunggu dulu (HTTP 429) if jumlah_sekarang > limit: sisa_waktu = await redis_client.ttl(key) raise HTTPException( status_code=429, detail={ "pesan": "Sabar ya, kamu manggilnya terlalu sering! Coba lagi nanti.", "tunggu_sekitar": f"{sisa_waktu} detik lagi" } ) # Kita balikin jumlah sekarang buat info nantinya return jumlah_sekarang, limit except HTTPException: raise except Exception as e: # Kalau Redis lagi error, mending kita bolehin aja request-nya # supaya user nggak keganggu. Kita sebut ini Fail Open! print(f"Duh, ada masalah di Redis nih: {e}") return None, limit@app.get("/api/data")async def ambil_data(request: Request): # Panggil satpam_api buat cek kuota pengguna jumlah, limit = await satpam_api(request) return { "isi": "Hore! Kamu berhasil dapet data rahasia ini.", "info_kuota": f"{jumlah}/{limit}" if jumlah else "Tanpa batas (Wah, Redis lagi libur!)" }if __name__ == "__main__": import uvicorn # Ayo kita jalanin servernya! uvicorn.run(app, host="0.0.0.0", port=8000)
Jadi begini cara kerjanya: tiap ada yang akses endpoint /api/data, fungsi satpam_api bakal ngecek IP pengunjung di Redis. Kalau IP tersebut baru pertama kali datang, kita kasih “jatah” selama 60 detik ke depan. Kalau ternyata dia terlalu rajin panggil API (lebih dari 10 kali semenit), server bakal langsung kasih respon “429 Too Many Requests”. Jadi server FastAPI kamu nggak bakal capek ngurusin permintaan yang berlebihan! Asyik kan?
Kesimpulan
Bikin API yang bisa jalan itu emang keren, tapi bikin API yang tangguh itu baru namanya luar biasa! Rate Limiting itu bukan cuma soal membatasi orang kok, tapi lebih ke menjaga supaya semuanya dapat jatah yang adil. Dengan pasang “pagar” yang bener di FastAPI, kamu sudah amanin server dari serangan DoS, bikin susah orang yang mau tebak password, dan pastinya bikin dompet aman dari tagihan server yang mendadak bengkak!
Ingat ya, tiap aplikasi itu punya “nafas” yang beda-beda. Jadi, jangan lupa buat selalu pantau trafik kamu dan sesuaikan angka batasannya ya! Jangan sampai satpamnya terlalu galak sampai pengguna asli malah susah masuk, tapi jangan terlalu lembek juga sampai pintu gampang jebol. Selamat mencoba pasang pagar di API kamu menggunakan FastAPI, dan semoga tidurnya makin nyenyak karena tahu servernya sudah punya tameng yang oke!
Gimana nih, sudah kepikiran mau pasang limit berapa buat API kamu? Kalau mau tau cara pasang limit yang beda-beda buat tiap user (misal user VIP dapet jatah lebih banyak), tanya-tanya aja ya di kolom komentar!

Leave a comment