# Rate Limiting API di NestJS dengan Redis: Panduan Produksi > Cara mengimplementasikan rate limiting terdistribusi di NestJS menggunakan @nestjs/throttler dan Redis — melindungi API Anda dari penyalahgunaan di skala apa pun. URL: https://www.matthewswong.com/id/blog/api-rate-limiting-nestjs-redis/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2025-06-10 - Updated: 2025-06-10 - Category: Web Dev Rate limiting adalah salah satu fitur yang terasa opsional sampai hari seseorang menemukan endpoint Anda dan mengirim 10.000 request dalam 60 detik, menjatuhkan database Anda. Modul @nestjs/throttler NestJS membuat implementasi rate limiting mudah, tapi penyimpanan in-memory default rusak ketika Anda melakukan scaling ke beberapa instance. Rate limiting berbasis Redis adalah pendekatan yang benar untuk produksi. ## Masalah dengan Rate Limiting In-Memory Default @nestjs/throttler menggunakan penyimpanan in-memory — Map yang melacak jumlah request per IP klien per jendela TTL. Ini berfungsi sempurna untuk deployment satu instance. Saat Anda menambahkan instance kedua di balik load balancer, instance A tidak tahu tentang request yang menekan instance B. Redis menyelesaikan ini dengan menyediakan state bersama di semua instance. ### Menginstal Redis Throttler Instal paket yang diperlukan: @nestjs/throttler dan @nest-lab/throttler-storage-redis. Paket throttler-storage-redis mengimplementasikan antarmuka ThrottlerStorage menggunakan Redis sebagai backend. Konfigurasikan ThrottlerModule di AppModule Anda dengan penyedia penyimpanan Redis. Daftarkan ThrottlerGuard secara global menggunakan token APP_GUARD di array providers Anda sehingga setiap route dilindungi secara default. > Dari mengimplementasikan rate limiting pada API NestJS ERP: gunakan beberapa konfigurasi throttle untuk tipe endpoint yang berbeda. Endpoint autentikasi publik (login, reset kata sandi) mendapatkan batas agresif: 5 request per menit. Endpoint API umum mendapatkan batas yang lebih longgar: 100 request per menit. Endpoint ekspor massal mendapatkan batas yang sangat ketat: 2 request per 5 menit. Gunakan decorator @Throttle() pada controller atau route tertentu untuk menimpa konfigurasi global. ## Mengimplementasikan Throttler dengan Redis Konfigurasi ThrottlerModule di AppModule: impor ThrottlerModule dengan array konfigurasi throttle (masing-masing memiliki nama, ttl dalam milidetik, dan limit). Opsi storage menunjuk ke ThrottlerStorageRedisService Anda. Daftarkan APP_GUARD dengan ThrottlerGuard di array providers. Setiap route dalam aplikasi Anda sekarang menegakkan rate limit. Endpoint yang harus melewati rate limiting (pemeriksaan kesehatan, pemantauan internal) menggunakan decorator @SkipThrottle(). ### Rate Limiting Kustom berdasarkan Pengguna vs IP Throttler default mengelompokan request berdasarkan alamat IP. Untuk API terautentikasi, Anda ingin mengelompokan berdasarkan ID pengguna — satu IP bisa mewakili seluruh tim perusahaan. Timpa metode getTracker() ThrottlerGuard untuk mengembalikan ID pengguna dari payload JWT jika terautentikasi, kembali ke IP untuk request yang tidak terautentikasi. > **Header Rate Limit dan Pengalaman Pengguna** > Saat request ditolak dengan 429 Too Many Requests, selalu sertakan header Retry-After — ini memberi tahu klien kapan mereka bisa mencoba lagi. Tanpanya, klien biasanya mengimplementasikan exponential backoff dari awal atau mencoba lagi segera (memperburuk masalah). Throttler NestJS menambahkan header X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset ke respons yang berhasil secara otomatis. Untuk request yang ditolak, tambahkan header Retry-After di ThrottlerExceptionFilter Anda. ## Strategi Kunci Redis dan TTL @nest-lab/throttler-storage-redis menyimpan state throttle di kunci Redis dengan format throttle:'<'tracker>:'<'ttl>. Setiap kunci memiliki TTL otomatis yang cocok dengan jendela throttle Anda. Saat TTL kedaluwarsa, kunci dihapus dan hitungan direset. Operasi INCR atomik Redis memastikan request bersamaan dari klien yang sama tidak melampaui batas secara bersamaan. ## Yang Saya Gunakan dan Mengapa Untuk API NestJS apa pun yang melayani lebih dari satu instance, throttling berbasis Redis dengan @nestjs/throttler + @nest-lab/throttler-storage-redis adalah standar saya. Pengaturan membutuhkan kurang dari satu jam dan memberikan perlindungan yang berarti terhadap penyalahgunaan. Saya mengonfigurasi tiga tingkat throttle: ketat untuk endpoint auth, standar untuk API biasa, dan longgar untuk endpoint publik read-only. ## Melampaui Rate Limiting: Defense in Depth Rate limiting adalah satu lapisan. Perlindungan API produksi membutuhkan banyak lapisan: (1) Rate limiting (NestJS Throttler + Redis) — mencegah banjir request. (2) Validasi input (class-validator + class-transformer pipes) — mencegah input yang cacat. (3) Guard autentikasi (Passport JWT) — mencegah akses yang tidak terautentikasi. (4) Guard otorisasi — mencegah mengakses sumber daya yang bukan milik Anda. (5) Pencegahan injeksi SQL (query berparameter Prisma). (6) Perlindungan DDoS tingkat jaringan (Cloudflare atau setara). ## Sumber & Bacaan Lanjut - NestJS Docs — Rate Limiting — https://docs.nestjs.com/security/rate-limiting - Wanago — API with NestJS #187: Rate Limiting Using Throttler — https://wanago.io/2025/03/03/api-nestjs-rate-limiting-throttler/ - DEV Community — Redis as Custom Storage for NestJS Rate Limiter — https://dev.to/zsevic/redis-as-custom-storage-for-nestjs-rate-limiter-4o9k ## Source links - https://docs.nestjs.com/security/rate-limiting - https://wanago.io/2025/03/03/api-nestjs-rate-limiting-throttler/ - https://dev.to/zsevic/redis-as-custom-storage-for-nestjs-rate-limiter-4o9k ## FAQ ### Mengapa rate limiting in-memory tidak berfungsi di deployment NestJS multi-instance? Default @nestjs/throttler menggunakan Map in-memory untuk melacak jumlah request per IP klien. Saat beberapa instance berjalan di balik load balancer, setiap instance memiliki penghitung yang terisolasi — sehingga klien bisa menghabiskan batas instance A dan tetap mengirim jumlah request yang sama ke instance B. Efektifnya, batas rate menjadi berlipat ganda sesuai jumlah instance. ### Bagaimana Redis menyelesaikan masalah rate limiting terdistribusi? Redis menyediakan state bersama di semua instance NestJS. Paket @nest-lab/throttler-storage-redis mengimplementasikan antarmuka ThrottlerStorage menggunakan Redis sebagai backend, sehingga setiap instance membaca dan menulis ke penghitung yang sama. Operasi INCR atomik Redis juga memastikan request bersamaan dari klien yang sama tidak bisa melampaui batas secara bersamaan. ### Mengapa rate limit pada API terautentikasi sebaiknya menggunakan ID pengguna, bukan alamat IP? Satu IP bisa mewakili seluruh tim perusahaan saat karyawan berbagi jaringan melalui NAT. Jika batas diterapkan per IP, 20 orang di perusahaan yang sama bisa secara kolektif memicu batas yang dirancang untuk satu pengguna individual. Menimpa metode getTracker() ThrottlerGuard untuk mengembalikan ID pengguna dari JWT mencegah false positive ini, sambil tetap menggunakan IP untuk request yang tidak terautentikasi. ### Tier throttle apa yang direkomendasikan dalam artikel ini, dan bagaimana cara penerapannya? Artikel ini merekomendasikan tiga tier berdasarkan sensitivitas endpoint: ketat (5 request per menit) untuk endpoint auth publik seperti login dan reset kata sandi, standar (100 request per menit) untuk endpoint API umum, dan sangat ketat (2 request per 5 menit) untuk endpoint ekspor massal. ThrottlerGuard global menegakkan default, dan decorator @Throttle() pada controller atau route tertentu menimpanya untuk kontrol yang lebih presisi. ### Apa yang harus disertakan dalam respons 429 agar klien mendapat pengalaman yang baik? Respons 429 Too Many Requests harus selalu menyertakan header Retry-After yang memberi tahu klien kapan tepatnya mereka bisa mencoba lagi. Tanpanya, klien biasanya mengimplementasikan exponential backoff dari awal atau langsung mencoba lagi, yang justru memperburuk masalah. Throttler NestJS secara otomatis menambahkan header X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset ke respons yang berhasil; ThrottlerExceptionFilter kustom dapat menambahkan Retry-After ke respons yang ditolak. --- - HTML version: https://www.matthewswong.com/id/blog/api-rate-limiting-nestjs-redis/ - English: https://www.matthewswong.com/en/blog/api-rate-limiting-nestjs-redis/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json