# 🚀 Roadmap Pengembangan: High Concurrency (1000 Users)

**Project:** Event Tryout Backend (NestJS & Prisma)

Dokumen ini disusun berdasarkan hasil analisis _boilerplate_ untuk menangani beban **1000 user concurrent** pada sistem Tryout. Fokus utama adalah pada performa, stabilitas, dan skalabilitas di atas VPS lokal (tanpa Docker).

---

## 🛠️ Fase 1: Optimasi Infrastruktur & Deployment

Fokus: Pemanfaatan sumber daya hardware secara maksimal dan efisiensi pengiriman data.

### [Problem] Single-Process Bottleneck

Secara default, Node.js hanya berjalan pada 1 CPU Core. VPS lokal dengan multi-core tidak akan terutilisasi dengan baik, menyebabkan request antre (latency tinggi).

- **Solusi:**
  - Gunakan **PM2 Cluster Mode**. Jalankan aplikasi dengan perintah: `pm2 start dist/main.js -i max`.
  - PM2 akan secara otomatis mengelola load balancing internal antar instance instance.

### [Problem] Static Assets Overhead

Menyajikan gambar soal atau sertifikat melalui proses NestJS (`app.useStaticAssets`) menghabiskan CPU and Memory yang seharusnya digunakan untuk logika bisnis.

- **Solusi:**
  - Gunakan **Nginx sebagai Reverse Proxy**.
  - Konfigurasikan Nginx untuk melayani folder `public/` secara langsung menggunakan direktif `location /public/ { alias ... }`.
  - Aktifkan Gzip atau Brotli compression di Nginx untuk memperkecil ukuran data.

---

## 🚦 Fase 2: Traffic Control & Security

Fokus: Menghindari blokade terhadap user sah sambil menjaga server dari serangan.

### [Problem] Restriktif Throttling

Konfigurasi `ThrottlerModule` saat ini (limit: 20/menit) akan memblokir user hampir seketika saat tryout dimulai.

- **Solusi:**
  - Perbarui `app.module.ts`: Tingkatkan `limit` ke minimal 150-300 per menit.
  - **Integrasi Redis:** Gunakan `ThrottlerStorageRedisService` agar counter rate-limit tersinkronisasi di semua instance PM2 Cluster.

---

## 💾 Fase 3: Database & Caching Strategy

Fokus: Menghindari _latency_ database dan menangani _write spikes_.

### [Problem] Query Latency & DB Connection Pool

1000 user yang melakukan query soal secara bersamaan akan menghabiskan slot koneksi database PostgreSQL.

- **Solusi:**
  - **Tuning Prisma:** Tambahkan parameter `connection_limit=50` (atau lebih sesuai spek VPS) pada `DATABASE_URL` di file `.env`.
  - **Resource Caching:** Cache hasil query bank soal di Redis. Soal tryout bersifat statis selama sesi berlangsung, jangan query ke DB berulang kali.

### [Problem] High Frequency Writes (Simpan Jawaban)

Setiap klik jawaban oleh user memicu transaksi database. 1000 user x setiap klik soal = tekanan tinggi pada disk I/O.

- **Solusi:**
  - **Write Buffering:** Simpan jawaban sementara di Redis menggunakan key `session:ans:{sessionId}`.
  - **Background Sync:** Gunakan cron job atau worker untuk memindahkan jawaban dari Redis ke PostgreSQL secara periodik atau saat sesi tryout berakhir.

---

## ⚡ Fase 4: Application Logic Optimization

Fokus: Mengurangi beban CPU pada "Hot Path".

### [Problem] CPU Intensive Hashing (Bcrypt)

Saat 1000 user login serentak dalam kurun waktu 1-5 menit, CPU akan terbebani oleh operasi `bcrypt.compare`.

- **Solusi:**
  - Pastikan `salt rounds` di angka 10 (standar).
  - Gunakan **Redis Session** (Refresh Token di Redis) agar validasi token tidak selalu membutuhkan query ke DB.

### [Problem] Interceptor Overhead

Global `TransformInterceptor` dan `HttpExceptionFilter` yang terlalu kompleks bisa menambah beban per request.

- **Solusi:**
  - Pastikan logika di interceptor tetap ringan. Hindari query DB di dalam interceptor global.

---

## 🧪 Fase Verifikasi (Load Testing)

Sebelum digunakan secara massal, lakukan pengujian berikut:

1. **Stress Test (K6):**

   ```javascript
   // Contoh sederhana k6 script
   import http from 'k6/http';
   import { check, sleep } from 'k6';

   export let options = {
     vus: 1000,
     duration: '5m',
   };

   export default function () {
     let res = http.get('http://vps-ip/api/events');
     check(res, { 'status is 200': (r) => r.status === 200 });
     sleep(1);
   }
   ```

2. **Monitoring Resource:** Pantau penggunaan RAM dan CPU menggunakan perintah `top` atau `htop` dan `pm2 monit`.

---

## 💡 Rekomendasi Tambahan

- **Log Management:** Matikan `console.log` di production. Gunakan logger seperti **Pino** yang asinkron dan sangat cepat.
- **Keep-Alive:** Pastikan koneksi DB ke PostgreSQL menggunakan `Keep-Alive` agar tidak melakukan _handshake_ berulang kali.

---

_Dibuat oleh Assistant - Tech Lead Role_