Belajar NATS - Request-Reply & Queue Groups

#Pendahuluan

Episode 4 memperkuat routing. Episode 5 ini mempersenjatai kalian dengan dua pola yang membuat NATS menjadi tulang punggung microservices: request-reply untuk komunikasi sinkron bergaya RPC, dan queue groups untuk membagi beban kerja secara horizontal.

Keduanya memakai mekanisme yang sudah kalian kenal — subjects — namun dengan semantik yang berbeda. Mari kita bedah satu per satu.

#Request-Reply: Pola RPC Microservices

#Cara Kerja di Balik Layar

Pola request-reply NATS bekerja dalam tiga langkah: pemanggil mempublish request ke subject dengan reply subject otomatis, server NATS menyisipkan reply subject tersebut ke header pesan, lalu handler mempublish jawaban ke reply subject yang sama.

client --> request ke subject:auth.login [reply: _INBOX.x]
             service auth menangkap subject
             service mempublish jawaban ke _INBOX.x
             client menerima jawaban

Subscriber handler yang memproses request tidak perlu tahu identitas pemanggil — cukup memakai msg.respond() untuk membalas.

#Memakai nats request dari CLI

Cara tercepat melihat pola ini hidup adalah lewat CLI:

nats reply 'auth.login' "OK: token-abc123"
nats request 'auth.login' '{"username":"arman"}'

nats reply 'auth.login' "OK: token-abc123" memasang handler yang membalas setiap request, dan nats request 'auth.login' '{...}' mengirim request lalu menunggu jawaban. Output CLI menampilkan OK: token-abc123.

#Timeouts dalam Request

Request-reply adalah operasi sinkron — pemanggil menunggu. Waktu tunggu harus dibatasi agar tidak menggantung:

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

Flag --timeout=2s di atas membuat CLI berhenti menunggu setelah 2 detik. Jika handler lambat, pemanggil mendapat error timeout alih-alih menggantung selamanya. Kebiasaan ini wajib ditiru di semua client library.

#Request-Reply dalam Client Library

#Client Python

Di nats-py, request-reply semudah memanggil fungsi:

Request-reply dengan nats-py

import asyncio
import nats
 
async def main():
    nc = await nats.connect("nats://localhost:4222")
 
    async def handler(msg):
        await msg.respond(b"pong")
 
    await nc.subscribe("ping", cb=handler)
    reply = await nc.request("ping", b"ping-request", timeout=2)
    print(reply.data)
 
    await nc.close()
 
asyncio.run(main())

await nc.request("ping", b"ping-request", timeout=2) mengirim request dan menunggu jawaban maksimal 2 detik. Di sisi lain, await msg.respond(b"pong") membalas request — dua baris inilah inti pola RPC NATS.

#Timeouts yang Benar

Aturan praktis timeouts di distributed systems: tetapkan timeout di pemanggil, dan tetapkan lebih kecil dari timeout handler di pemanggil atas. Jika service A memanggil B dan B memanggil C, timeout A terhadap B harus lebih kecil dari timeout B terhadap C — agar error tidak menumpuk berlapis.

#Queue Groups: Load Balancing Antar Consumer

#Konsep Queue Group

Queue group mengubah publish/subscribe menjadi competing consumers: sekelompok subscriber yang berbagi nama queue, dan setiap pesan hanya diterima satu anggota. Server NATS melakukan round-robin antar anggota.

nats sub 'jobs.process' --queue workers
nats sub 'jobs.process' --queue workers

Kedua perintah nats sub 'jobs.process' --queue workers membentuk satu queue group workers — dua proses worker berbagi pesan secara bergantian. Jika ada 10 pesan, masing-masing menerima sekitar 5.

#Scaling Consumer Secara Horizontal

Queue group adalah mekanisme scaling yang sangat sederhana: untuk menangani lebih banyak beban, cukup jalankan instance consumer tambahan dengan nama queue yang sama. Tidak ada perubahan konfigurasi server, tidak ada re-deploy.

publisher --> jobs.process --> worker-1 (queue: workers)
                            --> worker-2 (queue: workers)
                            --> worker-3 (queue: workers)

Gambar di atas menunjukkan tiga worker berbagi subject jobs.process — setiap pesan mendarat di satu worker saja. Berbeda dengan publish/subscribe biasa di mana semua subscriber menerima salinan.

#Queue Group vs Publish/Subscribe

nats sub subject --queue name mengubah subscriber biasa menjadi anggota queue group. Pilihan antara broadcast dan load balancing menentukan struktur sistem kalian.

#Queue Groups dalam Aplikasi

#Client Node.js

Di client library, queue group ditentukan saat subscribe:

Queue group dengan nats.js

import { connect, StringCodec } from "nats";
 
const nc = await connect({ servers: "nats://localhost:4222" });
const sc = StringCodec();
 
nc.subscribe("jobs.process", { queue: "workers" }, (err, msg) => {
  console.log("diproses oleh worker:", sc.decode(msg.data));
});
 
nc.publish("jobs.process", sc.encode("job-1"));

nc.subscribe("jobs.process", { queue: "workers" }, handler) memasang subscriber sebagai anggota queue workers. Jalankan dua instance file ini, publish beberapa job, dan perhatikan distribusi yang bergantian.

#Penutup

Episode 5 memperlengkapi kalian dengan dua pola komunikasi produktif: request-reply untuk RPC sinkron dengan nats request dan timeout yang disiplin, serta queue groups untuk load balancing horizontal antar consumer dengan perintah --queue.

Inti yang harus dibawa pulang:

• Request-reply memakai reply subject otomatis yang disediakan server.
• nats request dan nats reply memudahkan pengujian pola RPC dari CLI.
• Selalu tetapkan timeout pada request agar pemanggil tidak menggantung.
• Queue group membuat setiap pesan diterima tepat satu consumer.
• Scaling dilakukan dengan menambah instance consumer pada queue yang sama.
• Publish/subscribe untuk broadcast, queue group untuk load balancing.

Di episode 6 selanjutnya kita akan membahas CLI & client libraries — rangkaian perintah nats pub, nats sub, nats req, nats stream, nats consumer, dan nats account, lalu menulis program lengkap di Go, Python, dan Node.js untuk connect, publish, subscribe, dan request. Di sinilah perangkat kerja harian kalian mulai terbentuk.