Belajar NATS - Integrasi & Best Practice

#Pendahuluan

Episode 14 membangun skala. Episode 15 ini menghubungkan NATS dengan dunia luar dan merapikan praktiknya: kalian akan belajar memakai NATS sebagai broker MQTT untuk perangkat IoT, lalu merangkum best practice yang menjaga arsitektur tetap sehat — subject naming, backpressure, timeouts, dan pola event-driven yang benar.

Ini episode jembatan: sebagian besar isinya adalah kebiasaan yang akan kalian bawa sampai episode 22.

#MQTT Bridge: NATS sebagai Broker IoT

#Konsep MQTT di NATS

MQTT adalah protokol ringan untuk perangkat IoT. Sejak versi 2.10, NATS bisa menjadi broker MQTT langsung — perangkat yang bicara MQTT terhubung ke NATS tanpa gateway terpisah.

Mengaktifkan MQTT di NATS

mqtt {
  listen: "0.0.0.0:1883"
  no_auth_user: mqtt-user
  ack_wait: 30s
  max_ack_pending: 100
}

Blok mqtt mengaktifkan listener MQTT di port 1883. Perangkat IoT memakai protokol MQTT biasa, dan NATS memetakan topic MQTT ke subject NATS secara transparan.

#Memetakan Topic MQTT ke Subject NATS

MQTT punya topic, NATS punya subject. NATS menjembatani keduanya:

Subscribe topic MQTT dari CLI NATS

nats sub 'sensors.>'
mosquitto_pub -h localhost -t "sensors/temp" -m "24.5"

nats sub 'sensors.>' mendengarkan subject sensors.>, sementara perangkat MQTT publish ke topic sensors/temp yang otomatis dipetakan ke subject sensors.temp. Satu server melayani perangkat IoT dan microservices sekaligus.

#Kekuatan Integrasi MQTT

Karena MQTT terpetakan ke subject NATS, semua fitur NATS langsung berlaku untuk data IoT: stream JetStream untuk merekam data sensor, work queue untuk memproses, dan request-reply untuk kontrol perangkat. Tidak ada sistem tambahan.

#Best Practice: Subject Naming

#Konvensi yang Konsisten

Konsistensi penamaan menentukan keterbacaan sistem:

Gunakan dot sebagai pemisah hierarki: orders.created.eu.
Past tense untuk event, present tense untuk request.
Hindari wildcard saat publish; simpan untuk subscription.
Dokumentasikan skema subject di awal project.

Skema subject yang konsisten

domain.entity.action
orders.created, orders.cancelled
payments.charged, payments.refunded
sensors.temp.room-1

Skema domain.entity.action membuat setiap subject bisa dibaca sekaligus. Kalian akan bersyukur atas konvensi ini saat menulis permission atau debugging di episode 19.

#Best Practice: Backpressure

#Menjaga Publisher Tetap Terkendali

Backpressure mencegah consumer kewalahan. Di Core NATS, publisher tanpa limit bisa membanjiri subscriber lambat. Solusinya:

Pakai queue groups untuk menyebar beban antar worker.
Pakai pull consumer JetStream agar worker menarik pesan sesuai kapasitas.
Monitor pending count consumer secara rutin.

Cek pending consumer

nats consumer report ORDERS

nats consumer report ORDERS menampilkan jumlah pesan pending per consumer. Jika angkanya naik terus, itu sinyal backpressure dibutuhkan — tambah worker atau perlambat publisher.

#Best Practice: Timeouts

#Disiplin Waktu Tunggu

Timeout menjaga sistem tetap responsif di tengah kegagalan:

Request dengan timeout

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

Flag --timeout=2s memaksa request berhenti menunggu setelah 2 detik. Aturan rantai: timeout pemanggil harus lebih kecil dari timeout handler, agar error tidak menumpuk berlapis. Publish ke stream juga perlu ack dengan batas waktu untuk mengetahui apakah pesan benar-benar diterima.

#Best Practice: Pola Event-Driven

#Arsitektur Microservices yang Benar

Beberapa pola yang terbukti untuk microservices:

Event publish: service mempublish fakta yang terjadi, tanpa tahu siapa yang mendengarkan.
Request-reply untuk operasi yang butuh jawaban segera.
Job queue untuk tugas yang boleh diproses asinkron.
Streaming pipeline untuk aliran data berkelanjutan.

Pola event-driven dengan NATS

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

Alur orders service -> publish orders.created menunjukkan satu event dikonsumsi banyak service tanpa coupling langsung. Inilah inti decoupled architecture — dan tema yang akan kita sempurnakan di episode 21.

Tip

Mulai dengan satu pola per service: jangan mencampur request-reply dan streaming dalam satu alur tanpa alasan jelas. Kesederhanaan adalah aset terbesar arsitektur messaging.

#Penutup

Episode 15 menghubungkan NATS dengan dunia perangkat IoT lewat MQTT bridge dan merapikan praktik engineering: subject naming convention yang konsisten, backpressure untuk melindungi consumer, timeouts yang disiplin, serta pola event-driven yang benar untuk microservices.

Inti yang harus dibawa pulang:

NATS bisa menjadi broker MQTT hanya dengan blok mqtt di konfigurasi.
Topic MQTT dipetakan ke subject NATS; semua fitur JetStream berlaku untuk data IoT.
Gunakan pola domain-entity-action untuk penamaan subject.
Pull consumer dan queue groups adalah senjata utama melawan backpressure.
Timeout wajib pada request; lebih kecil di pemanggil daripada handler.
Satu event dipublish sekali, dikonsumsi banyak service tanpa coupling.

Di episode 16 selanjutnya kita akan membahas JetStream performance — high-throughput publish versi 2.14+, batching untuk publish massal, server-side message scheduling, scaling dengan replikasi dan partisi antar subject, tuning storage, serta benchmark menuju jutaan pesan per detik. NATS mulai menunjukkan taringnya.