Belajar NATS - Production-Ready Architecture

#Pendahuluan

Semua babak sebelumnya berujung pada satu pertanyaan: bagaimana merakit semuanya menjadi arsitektur production-grade? Episode 21 ini menjawabnya. Kalian akan merancang infrastruktur NATS yang andal, aman, dan terpantau — lalu menyusun pola aplikasi yang memanfaatkannya sepenuhnya.

Ini episode arsitek: sebagian besar isinya keputusan desain yang mengikat semua pelajaran sebelumnya.

#Fondasi Cluster

#Topologi 3 atau 5 Node

Pilihan pertama adalah ukuran cluster. 3 node untuk beban menengah dengan toleransi satu node mati; 5 node untuk production yang lebih besar dengan toleransi dua node.

server_name: nats-1
cluster {
  name: "nats-prod"
  listen: "0.0.0.0:6222"
}
jetstream {
  store_dir: "/data/jetstream"
  max_file_store: 100G
}

Blok jetstream menyimpan data di direktori persisten dan membatasi file store 100 GB. Setiap stream production memakai replicas: 3 agar tetap tersedia saat satu node turun.

#Memisahkan Node Perfektif

nats-1, nats-2, nats-3 (cluster JetStream)
  ├── client port 4222
  ├── route port 6222
  └── monitoring port 8222

Struktur nats-1, nats-2, nats-3 (cluster JetStream) menempatkan tiga node di host berbeda atau zona berbeda. Jangan letakkan semua node di satu mesin — itu bukan cluster, hanya single point of failure.

#Accounts dan JWT

#Isolasi Antar Tim

Arsitektur production memakai accounts untuk memisahkan domain:

• account ORDERS untuk service order dan stream terkait.
• account PAYMENTS untuk domain pembayaran.
• account ADMIN untuk tooling dan observability.

nsc add account ORDERS
nsc add user --account ORDERS order-service
nsc generate creds --account ORDERS --user order-service -o order-service.creds

nsc generate creds menghasilkan kredensial JWT untuk service. Setiap service memakai creds-nya sendiri, dengan permission yang dibatasi minimum. Jika perlu komunikasi lintas account, gunakan ekspor-impor seperti episode 12.

#TLS di Setiap Koneksi

#Enkripsi End-to-End

Semua port komunikasi harus memakai TLS: client, route cluster, gateway, dan monitoring.

tls {
  cert_file: "/etc/nats/certs/server-cert.pem"
  key_file: "/etc/nats/certs/server-key.pem"
  ca_file: "/etc/nats/certs/ca.pem"
  verify: true
}

Blok tls dengan verify: true mengaktifkan mutual TLS di semua koneksi. Client memakai URL tls:// dengan creds atau sertifikatnya masing-masing.

#Monitoring dan Alerting

#Satu Pusat Pengamatan

Arsitektur production tidak lengkap tanpa monitoring:

nats_exporter --> Prometheus --> Grafana --> alertmanager
$SYS events   --> notifikasi

Alur nats_exporter -> Prometheus -> Grafana menyatukan metrik seluruh cluster dalam satu dashboard. Alerting dibangun di atasnya: disk penuh, pending naik, node down — semuanya memicu notifikasi sebelum menjadi insiden.

#Disaster Recovery dengan Mirroring

#Cadangan Lintas Region

Mirroring memungkinkan cadangan stream di region lain:

name: ORDERS_DR
mirror:
  name: ORDERS
  external:
    api: nats://dr-cluster:4222

Blok mirror di cluster DR mencerminkan stream ORDERS dari cluster utama. Saat cluster utama gagal total, service dipindah ke DR dan stream dilayani dari salinannya.

#Pola Aplikasi: Event-Driven Microservices

#Satu Event, Banyak Konsumen

Pola pertama: service mempublish fakta yang terjadi, konsumen menangani sisanya.

orders --> publish orders.created --> stream ORDERS
                                        ├── notification service
                                        ├── inventory service
                                        └── analytics worker

Alur orders -> publish orders.created -> stream ORDERS menunjukkan event dikonsumsi banyak service tanpa coupling. Setiap service berlangganan dari stream dengan consumer-nya sendiri — masing-masing dengan posisi baca independen.

#Pola Aplikasi: Request-Reply API

#API Internal yang Cepat

Pola kedua: request-reply untuk operasi yang butuh jawaban segera.

nats request auth.login '{"user":"arman"}' --timeout=2s

nats request auth.login mewakili pola API internal: service menanyakan status, melakukan lookup, atau menjalankan verifikasi, dan menunggu jawaban. Timeout yang disiplin menjaga pemanggil tidak menggantung.

#Pola Aplikasi: Job Queue dan Streaming Pipeline

#Pekerjaan Asinkron dan Aliran Data

Pola ketiga dan keempat: job queue untuk tugas asinkron, streaming pipeline untuk aliran berkelanjutan.

event-driven microservices -> orders.created dikonsumsi banyak service
request-reply API          -> auth.login, users.get
job queue                  -> stream JOB + pull consumer
streaming pipeline         -> ingestion -> enrich -> store

Skema streaming pipeline -> ingestion -> enrich -> store membentuk rangkaian stage: data masuk, dienrich, lalu disimpan. Setiap stage adalah consumer pada stream-nya sendiri, bisa diskalakan terpisah.

#Penutup

Episode 21 merakit arsitektur production-grade: cluster 3 atau 5 node dengan JetStream dan replicas, accounts dengan JWT untuk isolasi, TLS di semua koneksi, monitoring dan alerting yang terpusat, disaster recovery via mirroring lintas region, serta empat pola aplikasi — event-driven microservices, request-reply API, job queue, dan streaming pipeline.

Inti yang harus dibawa pulang:

• Cluster 3 node toleran satu node mati; 5 node toleran dua.
• Setiap stream production memakai replicas 3.
• Accounts dan JWT memisahkan domain dengan permission minimal.
• TLS wajib di semua port: client, route, dan monitoring.
• Monitoring dan alerting mencegah masalah menjadi insiden.
• Mirroring lintas region adalah dasar disaster recovery.
• Empat pola aplikasi: event-driven, request-reply, job queue, dan streaming.

Di episode 22 selanjutnya — episode terakhir — kita akan membahas ekosistem alternatif & refleksi akhir — perbandingan mendalam NATS dengan Kafka, RabbitMQ, MQTT, dan Redis Streams, kapan memilih masing-masing, rekap perjalanan kalian dari episode 0, serta masa depan NATS di edge dan cloud. Perjalanan Belajar NATS menuju titik final.