Kenapa Monolith Wajib Dijalankan Multi-Instance? (Single vs Multi-Instance Explained)

Ringkasan isi video (Single-Instance vs Multi-Instance untuk Monolith)

Video membahas kapan “monolith” lebih tepat dijalankan sebagai single instance atau multi-instance (beberapa proses/app instance dari source code yang sama) pada satu bare metal (mis. puluhan core, RAM besar). Intinya: multi-instance sering lebih aman/lebih stabil, tetapi tetap tergantung apakah aplikasi stateless atau stateful, serta pertimbangan performa dan operasional.

---

1) Pertimbangan utama: Stateless vs Stateful (problem session/state)

• Aplikasi bisa di-scale out dengan menjalankan source code yang sama di 2 instance.
• Kunci keputusan: aplikasi itu stateless atau stateful.

Contoh masalah stateful (dengan Load Balancer)

• User login di instance A.
• Request berikutnya diarahkan ke instance B.
• Jika session/login tersimpan lokal di instance masing-masing, user bisa “dianggap tidak login” karena session tidak ada di instance B.
• Dampaknya:
  • user perlu login ulang
  • membingungkan
  • sangat bergantung pada timing, mis. timeout atau session expiry

Mitigasi yang disebut

• Sticky sessions (agar user tetap ke instance yang sama).
• Namun penulis menilai lebih baik memastikan layanan memang stateless; jika terlalu stateful, mengubah arsitektur agar lebih stateless dianggap lebih aman.

Kesimpulan bagian ini

• Multi-instance wajib dipikirkan matang bila aplikasi stateful, karena problem session bisa muncul.

---

2) Jika tetap single-instance: risiko GC pause (khususnya saat traffic tinggi)

• Single instance yang melayani jumlah request besar (mis. disebut 500.000 request) dapat mengalami bottleneck dari Garbage Collection (GC).
• Konsep yang dijelaskan:
  • GC dapat memicu “kemacetan”/server macet karena GC bersifat stop-the-world (menahan eksekusi).
  • Walau durasinya mungkin kecil, dampaknya besar karena antrian request bertambah.
• Solusi yang disarankan:
  • bila memungkinkan, gunakan multi-instance agar efek GC tidak melumpuhkan seluruh layanan sekaligus.

---

3) Resource contention saat multi-instance: Redis “greedy” dan penanganannya dengan memory limit

Saat multi-instance berjalan dan ada komponen seperti Redis, ada risiko berebut resource:

• Tiap instance/komponen bisa butuh RAM berbeda (contoh: 4GB, 16GB, dst).
• Jika tidak dibatasi, bisa saling mengambil CPU/RAM hingga berujung crash atau instabilitas.

Penanganan yang disarankan

• Gunakan memory limit untuk membatasi batas RAM per komponen/instance, sehingga tiap proses punya “territory” dan tidak saling menghabisi resource.

---

4) Limit OS/Linux: kebutuhan menaikkan file descriptor untuk beban tinggi

• Jika menangani banyak request, pastikan file descriptor limit mencukupi.
• Konsep:
  • di Linux, setiap request bisa berujung pada kebutuhan membuka/membuat file descriptor.
  • batas default yang umum disebut sekitar 1024.
• Jika targetnya 500.000 requests, perlu tuning agar file descriptor limit tidak jadi bottleneck.

---

5) Penempatan reverse proxy / Docker: overhead file descriptor & model jaringan

• Disebut ada skema reverse proxy / web server dan pertanyaan apakah reverse proxy dimasukkan ke Docker atau dibiarkan di luar.
• Alasan yang disinggung:
  • Jika berada di dalam Docker, bisa ada overhead kebutuhan file descriptor dan overhead di layer networking/container.
  • Jika di luar Docker, overhead bisa lebih terkontrol/lebih efisien.

---

6) Go runtime dan “work stealing” lintas CPU/NUMA: risiko latency

Video memberi fokus teknis untuk aplikasi (contoh Golang) dengan goroutine dan scheduling:

• Ada mekanisme work stealing antar CPU (atau antar CPU set).
• Masalahnya:
  • Bare metal bisa punya lebih dari satu CPU/NUMA node.
  • Jika goroutine/work “dicuri” lintas CPU set berbeda, bisa terjadi cache latency (mis. L3 cache miss / perpindahan data).
  • Dampaknya terasa saat beban request besar (mis. konteks 500.000 request).

Solusi yang disarankan

• Saat menggunakan Docker, tentukan CPU set per instance (CPU pinning / CPU affinity).
• Contoh: pilih range CPU tertentu untuk tiap instance agar goroutine tidak sering steal lintas set.

---

7) Database connection pooling: pakai PGBouncer untuk stabilitas

Setelah CPU pinning dan segregasi instance, penulis menyarankan penggunaan PG Bouncer (PGBouncer) terutama jika menggunakan PostgreSQL:

• tiap instance sebaiknya punya pool connection yang lebih terisolasi
• alur: instance → PGBouncer → Postgres

Manfaat

• Kontrol jumlah koneksi lebih stabil (mengurangi lonjakan koneksi langsung ke Postgres).
• Pooling/management koneksi lebih merata dan terkontrol.

---

Kesimpulan video

• “Monolith harus jalan single instance” adalah mitos.
• Keputusan single vs multi-instance tergantung kondisi aplikasi:
  • jika stateful dan sulit diubah → single instance bisa dipertimbangkan (menghindari problem session)
  • jika ingin skalabilitas dan stabilitas performa → multi-instance sering lebih baik (mengurangi dampak GC pause, isolasi resource, dan mengurangi contention)
• Untuk sistem “big banks” (core/bank), ada contoh tetap single instance karena alasan stateful dan kekhawatiran perubahan kode berdampak besar.

---

Main speakers / sources

• Pembicara utama: narator video (nama tidak disebut; pembukaan “Hi everybody…” dan penjelasan langsung).
• Sumber teknis yang dirujuk:
  • Load Balancer, session
  • Garbage Collection (GC)
  • Redis
  • Linux file descriptor limit
  • Docker CPU pinning/NUMA
  • Goroutine & work stealing (Go)
  • PGBouncer
  • PostgreSQL