Belajar NATS - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Episode 1 memberi kalian alasan mengapa NATS ada. Episode 2 ini turun satu level: bagaimana NATS bekerja di balik layar. Ini adalah fondasi arsitektural — setelah episode ini, istilah seperti subject, wildcard, queue group, dan stream akan menjadi kosakata sehari-hari kalian.

Kita akan membedah model routing berbasis subjects, tiga pola komunikasi yang didukung satu server, lapisan JetStream sebagai persistence engine, serta komponen-komponen yang membentuk ekosistem NATS. Pahami dengan tenang; episode 3 sampai 22 akan membangun di atas konsep ini.

#Subjects: Sistem Routing NATS

#Subject sebagai Token Bertitik

Inti routing NATS adalah subject: string berbasis dot yang menjadi alamat pesan. Contoh nyata:

orders.created
orders.created.eu
payments.charged
notifications.email.sent

Tidak ada deklarasi sebelumnya — publisher cukup mengirim ke subject dan subscriber yang tertarik akan menerimanya. Urutan token menggambarkan hierarki: orders.created dan orders.created.eu adalah subject yang berbeda, dengan eu sebagai detail lebih spesifik dari orders.created.

Subject bukan topik dengan partisi seperti Kafka. Ia murni string routing yang dipisahkan titik, dan tidak menyimpan state apa pun.

#Wildcard untuk Berlangganan

Subscriber bisa berlangganan ke banyak subject sekaligus memakai wildcard:

• * mencocokkan satu token saja.
• > mencocokkan satu atau lebih token sampai akhir.

nats sub 'orders.*'
nats sub 'orders.>'

nats sub 'orders.*' menerima orders.created dan orders.cancelled, tapi tidak orders.created.eu. Sementara nats sub 'orders.>' menerima semua pesan yang dimulai orders.. Aturan ini akan dibahas mendalam di episode 4, termasuk implikasinya terhadap permission.

#Pola Komunikasi Utama

#Publish/Subscribe

Pola paling dasar: publisher mengirim pesan ke subject, semua subscriber yang berlangganan menerima salinan. Pesan tanpa subscriber akan hilang di Core NATS — tidak diantrekan.

publisher --pesan--> subject:orders.created --> subscriber A
                                            --> subscriber B

#Request/Reply

NATS juga menyediakan pola request-reply: pengirim mengirim request ke subject dengan harapan ada reply. Server menyediakan reply subject otomatis, dan client yang merespons mempublish jawaban ke subject tersebut. Ini menjadi dasar pola RPC antar service.

#Queue Groups

Queue group mengubah perilaku publish/subscribe: dari sekelompok subscriber yang sama-sama berlangganan subject, hanya satu anggota yang menerima setiap pesan — distribusi bergantian untuk load balancing.

nats sub orders.created --queue workers

Perintah nats sub orders.created --queue workers menempatkan subscriber ke queue workers; dua atau lebih subscriber di queue yang sama membagi beban pesan secara bergantian. Ini pola competing consumers yang akan dibahas penuh di episode 5.

#JetStream: Lapisan Persistence

#Dari Pesan Sekali Lalu Menjadi Stream

Core NATS tidak menyimpan pesan. JetStream mengubah itu: pesan yang dipublish ke subject bisa ditangkap ke sebuah stream — log pesan yang tahan lama dengan retention policy. Stream kemudian dibaca oleh consumer, baik secara push maupun pull.

publisher --> subject:orders.> --> stream ORDERS --> consumer --> aplikasi

Alur di atas memperkenalkan konsep kunci JetStream: stream menyimpan, consumer membaca. Detail lengkap tentang retention, ack, dan durability akan dibahas di episode 7 sampai 9.

#Mengapa Persistence Diperlukan

Dengan JetStream, NATS menyediakan jaminan at-least-once: pesan diack oleh consumer, dan jika tidak terack dalam waktu tertentu, pesan dikirim ulang. Ini membuka pintu untuk workload yang tidak bisa kehilangan pesan — payment, job queue, event sourcing — tanpa keluar dari ekosistem NATS.

#Komponen Ekosistem NATS

#Satu Server, Banyak Peran

nats-server adalah daemon yang menjalankan semuanya: routing Core NATS, request-reply, queue groups, dan JetStream. Di sekelilingnya ada:

• nats CLI: toolkit admin untuk publish, subscribe, dan manajemen stream.
• Client libraries: resmi untuk Go, Python, Node.js, dan banyak bahasa lain.
• nats-box: container yang berisi server dan CLI lengkap, praktis untuk eksperimen cepat.
• Monitoring endpoints: port 8222 menyediakan /varz, /connz, /jsz, dan /subsz.

curl -s http://localhost:8222/varz | head -n 20

curl -s http://localhost:8222/varz mengembalikan JSON berisi status server, koneksi aktif, dan jumlah pesan — salah satu dari lima endpoint observability yang akan dibahas di episode 18.

#Penutup

Episode 2 membekali kalian model mental arsitektur NATS: routing berbasis subjects dengan wildcard, tiga pola komunikasi yang didukung satu server, JetStream sebagai lapisan persistence, dan komponen ekosistem yang saling melengkapi. Istilah subject, wildcard, queue group, dan stream kini bukan lagi kosakata asing.

Inti yang harus dibawa pulang:

• Subject adalah string bertitik yang menjadi alamat routing; tidak perlu deklarasi awal.
• Wildcard * mencocokkan satu token, > mencocokkan sisa token.
• Publish/subscribe menyebar ke semua subscriber; queue group membagi beban.
• Request-reply memakai reply subject otomatis untuk pola RPC.
• JetStream menambahkan stream dan consumer untuk persistence dan at-least-once.
• Ekosistem terdiri dari nats-server, nats CLI, client libraries, nats-box, dan monitoring endpoints.

Di episode 3 selanjutnya kita akan membahas setup & first connect — menjalankan nats-server langsung atau via Docker, menyusun konfigurasi minimal, memakai nats pub, nats sub, dan nats server check, serta menghubungkan client library pertama ke server NATS. Saatnya praktik!