Belajar NATS - Sejarah, Latar Belakang & Mengapa Membutuhkan NATS

#Pendahuluan

Episode 0 sudah memastikan environment kalian siap. Sekarang saatnya memahami mengapa NATS ada. Episode 1 ini menjawab tiga pertanyaan besar: dari mana NATS berasal, masalah apa yang dia pecahkan, dan mengapa kalian — sebagai engineer yang membangun microservices atau sistem event-driven — membutuhkannya.

Banyak orang mulai memakai NATS karena tutorial, padahal memahami latar belakangnya jauh lebih berharga. Dengan tahu masalah yang diselesaikan, kalian akan lebih mudah memutuskan kapan memakai NATS, kapan tidak, dan bagaimana memposisikannya dalam arsitektur. Mari kita mulai dari awal cerita.

#Sejarah NATS

#Lahir dari Derek Collison

NATS diciptakan oleh Derek Collison sekitar tahun 2011 saat ia bekerja di Apcera. Latar belakangnya bukan kebetulan: Collison adalah veteran infrastruktur messaging dan cloud, dan ia melihat bahwa broker messaging yang ada saat itu terlalu berat, kompleks, dan sulit diskalakan. Ia merancang sistem yang sebaliknya: sangat ringan, sangat cepat, dan sangat sederhana.

Nama "NATS" sendiri dipinjam dari inovasi tata bahasa oleh Noam Chomsky — NATS singkatan dari Neural Autonomic Transport System. Dari awal, desainnya dibentuk agar broker bisa "diam" secara cerdas: jangan simpan apa pun, jangan rekayasa berlebihan, hanya kirim pesan secepat mungkin.

#Core NATS lalu JetStream

Perjalanan NATS terbagi dalam dua era besar:

Core NATS dirancang sedemikian ringan — ia tidak menyimpan pesan apa pun. JetStream, yang lahir pada 2020, menambahkan lapisan persistence berbasis file langsung ke dalam server, sehingga NATS mendapatkan streaming yang tahan lama tanpa membutuhkan komponen terpisah.

#Status CNCF Graduated

NATS adalah salah satu proyek yang berhasil mencapai status graduated di Cloud Native Computing Foundation (CNCF) — level tertinggi kedewasaan proyek open-source. Artinya: tata kelola sehat, komunitas aktif, dan teknologi terbukti dipakai di produksi oleh banyak perusahaan. Pengembangan aktif berlangsung di nats.io dan GitHub di bawah organisasi nats-io.

which nats-server && nats-server -v

Jika nats-server -v menampilkan versi 2.14.x, kalian sudah berada di versi terbaru yang akan dibahas di episode 20.

#Masalah yang Diselesaikan NATS

#Sangat Ringan dan Hemat Resource

Masalah pertama yang dipecahkan NATS adalah bobot. Satu binary nats-server berukuran sekitar 15 MB dengan memory footprint kecil — cukup untuk dijalankan di Raspberry Pi atau perangkat edge. Bandingkan dengan broker modern yang membutuhkan ratusan MB RAM dan konfigurasi cluster rumit hanya untuk memulai.

nats-server    ~15 MB binary, single process
apache-kafka   membutuhkan broker + zookeeper/kraft, JVM heavy
rabbitmq       Erlang/OTP runtime, memory ratusan MB

Ringan bukan berarti lemah: NATS tetap mampu memproses jutaan pesan per detik dengan latensi milidetik, yang akan kita benchmark di episode 16.

#Simplicitas: Subjects Tanpa Konfigurasi Kompleks

Masalah kedua adalah kompleksitas. Di NATS, routing dilakukan lewat subjects — string bertitik seperti orders.created — tanpa perlu topik, partisi, atau konfigurasi queue yang rumit. Publisher cukup mengirim ke subject, subscriber cukup mendengarkan subject itu.

Satu server NATS sudah mendukung tiga pola komunikasi sekaligus: publish/subscribe, request-reply, dan queue groups. Tidak ada komponen terpisah untuk masing-masing pola. Inilah simplicitas yang jarang dimiliki broker lain.

#High Throughput dengan At-Least-Once

Masalah ketiga adalah jaminan pengiriman. Core NATS memberikan at-most-once yang sangat cepat; JetStream menambahkan at-least-once melalui acknowledgment dan redelivery. Ditambah lagi, NATS menyediakan KV store dan object store bawaan sehingga data aplikasi tidak perlu berpindah ke sistem lain.

Pesan sampai sekali vs bisa berulang

core_nats   = "publish sekali, terkirim paling banyak sekali"
jetstream   = "publish sekali, dijamin terkirim minimal sekali dengan ack"
kv_store    = "penyimpanan key-value dengan history dan TTL"

Model jetstream di atas menjadi andalan untuk workload yang tidak boleh kehilangan pesan — dan akan menjadi tema besar mulai episode 7.

#NATS vs Pendekatan Lain

#Posisi di Pasar Messaging

NATS tidak sendirian. Sebagai orientasi awal, berikut peta singkat yang akan dibahas penuh di episode 22:

• Kafka: streaming berstateful, partisi, replay, tetapi berat dan kompleks.
• RabbitMQ: routing berbasis exchange yang kaya, namun memory footprint besar.
• MQTT: protokol IoT ringan, cocok untuk perangkat terbatas; NATS juga bisa menjadi broker MQTT.
• Redis Streams: streaming dalam Redis yang familier, tapi tanpa fitur JetStream seperti durabilitas terdistribusi.

ringan, sederhana, cepat            berat, stateful, kompleks
nats ------------------------------ kafka
        mqtt      redis-streams        rabbitmq

Posisi nats berada di ujung kiri spektrum: memilih NATS berarti memprioritaskan kesederhanaan, kecepatan, dan efisiensi resource — sambil tetap menyediakan JetStream ketika persistence dibutuhkan.

#Penutup

Episode 1 memberi kalian konteks: NATS lahir dari tangan Derek Collison pada 2011 sebagai jawaban atas kompleksitas broker messaging, berkembang dari Core NATS ke JetStream, dan kini menjadi proyek CNCF graduated yang dikembangkan di nats.io. Dia menyelesaikan tiga masalah besar: bobot yang ringan, kompleksitas routing, dan kebutuhan at-least-once dengan persistence bawaan.

Inti yang harus dibawa pulang:

• NATS dibuat Derek Collison sekitar 2011 dengan filosofi ringan, sederhana, dan cepat.
• Core NATS murni publish/subscribe tanpa persistence; JetStream menambahkannya pada 2020.
• NATS berstatus CNCF graduated dengan pengembangan aktif di nats.io.
• Satu binary ~15 MB cukup untuk edge dan Raspberry Pi.
• Subjects menangani routing tanpa konfigurasi kompleks; tiga pola komunikasi dalam satu server.
• NATS menyediakan at-least-once, KV store, dan object store built-in.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur utama — bagaimana subjects bekerja di balik layar, peran wildcard dalam routing, pola komunikasi publish/subscribe, request-reply, dan queue groups, serta komponen-komponen NATS seperti nats-server, nats CLI, client libraries, dan nats-box. Ini adalah fondasi arsitektural yang akan menemani seluruh series.