Belajar System Design - Message Queue & Event Streaming

#Pendahuluan

Setelah di episode 5 kita memahami database indexing dan query optimization, pada episode ini kita masuk ke komponen infrastruktur yang mengubah synchronous systems menjadi asynchronous: message queue dan event streaming. Dua konsep ini adalah jantung dari microservices, event-driven architecture, dan hampir semua sistem yang perlu handle traffic burst atau decouple services.

Bayangkan sistem e-commerce: saat user checkout, order harus disimpan, inventory dikurangi, email dikirim, dan analytics dicatat. Jika semua dilakukan synchronous (satu per satu), checkout menjadi lambat dan semua layanan tightly coupled. Dengan message queue, checkout hanya menyimpan order lalu emit event — layanan lain memproses async. Inilah yang membuat sistem bisa scale dan resilient.

#Task Queue

Task queue menyimpan tugas-tugas yang harus diproses oleh worker secara async.

#Bull (Node.js)

Bull queue pattern

Producer → Queue → Worker → Process task
                  ↓
            Failed → Retry (max 3x) → Dead Letter Queue

Retry strategy: exponential backoff (tunggu 1s, 2s, 4s, dst).
Concurrency: jumlah worker yang parallel memproses task.
Priority: task penting diproses lebih dulu.

#Beanstalkd

Simple, cepat, dan lightweight. Interface: put, reserve, delete. Cocok untuk job queue yang tidak butuh fitur kompleks.

#Message Broker: RabbitMQ

RabbitMQ adalah message broker yang mendukung berbagai model routing.

#Routing Models

Model	Cara Kerja	Contoh
Direct	Routing key exact match	`order.created` → notification worker
Fanout	Broadcast ke semua queue	Log event → semua consumer
Topic	Wildcard routing (`*`, `#`)	`order.*` → semua event order
Headers	Berdasarkan message headers	Priority queue

#Dead-Letter Queue (DLQ)

Pesan yang gagal diproses (retry habis) dikirim ke DLQ untuk investigasi manual.

DLQ pattern

Queue → Worker → Gagal 3x → DLQ → Alert → Developer investigasi

#Retry Strategy

Strategy	Penjelasan	Kapan Pakai
Fixed interval	Retry tiap N detik	Simple tasks
Exponential backoff	Retry dengan interval meningkat	Network-dependent tasks
Exponential + jitter	Backoff + randomness	Mengurangi thundering herd

#Event Streaming: Apache Kafka

Kafka bukan sekadar message queue — ia adalah distributed event streaming platform yang menyimpan events secara persisten.

#Konsep Dasar Kafka

Kafka architecture

Producer → Topic (Partition 0, 1, 2) → Consumer Group
                   ↓
            Partition → log append-only (persistent)

Konsep	Penjelasan
Topic	Kategori events (contoh: `order-events`)
Partition	Sub-divisi topic untuk parallelism
Consumer Group	Sekumpulan consumer yang share beban
Offset	Posisi consumer dalam partition

#Kafka vs RabbitMQ

Aspek	Kafka	RabbitMQ
Model	Event streaming (persistent log)	Message broker (queue)
Retention	Long-term (days/years)	Hingga consumed
Replay	Bisa replay dari offset tertentu	Tidak bisa
Throughput	Sangat tinggi (jutaan msg/detik)	Tinggi (ratusan ribu msg/detik)
Use case	Event sourcing, log aggregation, real-time analytics	Task queues, RPC, simple messaging

#Consumer Group & Offset Management

Consumer group parallelism

Topic: orders (4 partitions)
Consumer Group A:
  Consumer 1 → Partition 0, 1
  Consumer 2 → Partition 2, 3

Jika consumer crash, partition dialihkan ke consumer lain dalam group yang sama. Offset disimpan untuk melanjutkan dari terakhir diproses.

#Exactly-Once Semantics

Kafka mendukung exactly-once semantics lewat:

Idempotent producer: produces tidak duplikat meskipun retry.
Transactional writes: beberapa topic ditulis atomically.
Consumer offset commit dalam transaksi: offset dan processing atomically.

#Kapan Pakai Queue vs Streaming

Skenario	Rekomendasi
Job processing (email, image resize)	Queue (Bull/RabbitMQ)
Inter-service communication	Queue atau streaming
Event sourcing (audit trail)	Kafka (persistent, replayable)
Real-time analytics	Kafka (high throughput)
Simple async task	Queue (RabbitMQ/Bull)
Log aggregation	Kafka (persistent, scalable)

#Praktik: Pipeline Order Processing

100%

Order processing flow

1. User POST /orders → API save order ke DB → emit "order.created" ke Kafka
2. Inventory Worker: kurangi stock → emit "inventory.reserved"
3. Payment Worker: proses pembayaran → emit "payment.processed"
4. Notification Worker: kirim email "order confirmed"

Setiap worker berjalan async dan independently — jika notification service down, order tetap diproses. Worker lain memproses event saat service recovery.

Note

Dalam production, selalu set timeout pada consumer dan retry limit. Consumer yang memproses terlalu lama (stuck) akan memblok queue. Gunakan visibility timeout untuk memastikan message yang gagal diproses kembali ke queue.

#Penutup

Inti yang harus dibawa pulang:

Task queue (Bull/Beanstalkd) untuk job async sederhana; RabbitMQ untuk routing complex; Kafka untuk event streaming persistent.
Dead-letter queue wajib untuk menangani message yang gagal diproses.
Retry strategy: exponential backoff + jitter untuk mengurangi thundering herd.
Kafka powerful untuk event sourcing dan real-time analytics, tapi lebih kompleks dari RabbitMQ.
Async processing decouple services — mengurangi latency dan meningkatkan fault tolerance.

Di episode 7 selanjutnya kita akan membahas API design & best practices — REST, GraphQL, gRPC, rate limiting, dan kapan menggunakan masing-masing. API adalah kontrak antara frontend dan backend — desain yang baik mengurangi friction dan mempercepat development!