Distributed Lock vs Message Queue (BullMQ, RabbitMQ) vs Kafka — Mengatasi Race Condition di Sistem Terdistribusi

🚀 Pendahuluan

Dalam sistem terdistribusi, dua masalah klasik yang sering muncul adalah:

1. Race condition — dua node memodifikasi data yang sama dalam waktu bersamaan.

2. Load tinggi — server harus membagi beban dengan mereplikasi proses ke banyak node.

Untuk mengatasi ini, developer biasanya mengenal teknologi seperti Redis Redlock, etcd, ZooKeeper, BullMQ, RabbitMQ, dan Kafka.
Namun, tidak semuanya punya peran yang sama.

Artikel ini menjelaskan perbedaan antara:

• Distributed Lock System,

• Message Queue System (BullMQ, RabbitMQ), dan

• Event Streaming Platform (Kafka).

🔒 1. Distributed Lock — Mencegah Race Condition Langsung

Distributed lock digunakan untuk memastikan hanya satu proses atau node yang dapat mengubah data tertentu dalam satu waktu, meskipun sistem berjalan di banyak server.

🧠 Tujuan utama:

Menjamin eksklusivitas akses terhadap resource bersama untuk mencegah race condition.

⚙️ Cara Kerja Singkat

• Server A membuat lock (misalnya kunci di Redis/etcd).

• Server B yang mencoba mengakses data yang sama harus menunggu hingga lock dilepas.

• Setelah Server A selesai, lock dihapus, dan server lain boleh melanjutkan.

Dengan begitu, hanya satu server di seluruh cluster yang dapat melakukan operasi write (menulis atau mengubah data) terhadap resource yang sama.

🧩 Contoh Tools Populer

💻 Contoh Implementasi (Redis Redlock)

import { createClient } from 'redis';
import { Redlock } from 'redlock';

const client = createClient();
await client.connect();

const redlock = new Redlock([client]);

await redlock.using(['lock:balance:123'], 5000, async () => {
  // hanya satu proses di cluster yang bisa menjalankan kode ini
  await updateBalance();
});

📌 Gunakan distributed lock ketika:

• Kamu ingin memastikan hanya satu proses yang bisa memperbarui resource bersama (saldo, stok, transaksi).

• Kamu punya sistem terdistribusi yang berjalan paralel di banyak server.

📨 2. Message Queue — Mengatur Antrian dan Distribusi Pekerjaan

Message queue system seperti BullMQ dan RabbitMQ digunakan untuk mengantri dan mendistribusikan pekerjaan secara asynchronous.

Mereka tidak melakukan locking terhadap resource, tetapi dapat mengurangi race condition secara tidak langsung dengan mengatur urutan eksekusi task. Message queue bekerja di level sistem terdistribusi (multi server).

🧠 Tujuannya:

Mengatur kapan dan bagaimana pekerjaan dieksekusi agar beban sistem terdistribusi dengan rapi.

🐂 BullMQ (Redis-based)

BullMQ adalah message queue modern berbasis Redis, populer di ekosistem Node.js.
Ia memungkinkan pembuatan job queue, penjadwalan, dan retry mechanism.

import { Queue, Worker } from 'bullmq';

const emailQueue = new Queue('email');

// producer
await emailQueue.add('sendEmail', { to: 'user@example.com' });

// consumer
const worker = new Worker('email', job => sendEmail(job.data.to));

Kelebihan BullMQ:

• Setup sederhana (cukup Redis).

• Dukungan untuk delay, retry, dan concurrency.

• Cocok untuk proyek Node.js kecil–menengah.

🐇 RabbitMQ (AMQP-based)

RabbitMQ adalah broker pesan klasik berbasis protokol AMQP.
Konsepnya mirip BullMQ tapi lebih matang dan lintas bahasa.

// producer
channel.sendToQueue('email', Buffer.from(JSON.stringify({ to: 'user@example.com' })));

// consumer
channel.consume('email', msg => sendEmail(JSON.parse(msg.content)), { noAck: true });

Kelebihan RabbitMQ:

• Stabil, mature, dan lintas bahasa (Node, Java, Python, Go).

• Mendukung routing dan acknowledgment kompleks.

• Cocok untuk sistem besar dengan beban tinggi.

🧩 Kesimpulan BullMQ & RabbitMQ

🌊 3. Kafka — Event Streaming Platform

Kafka berbeda dari queue biasa — ia adalah event log terdistribusi.
Kafka menyimpan event secara berurutan dan persisten sehingga bisa dibaca berulang oleh banyak konsumer.

🧠 Tujuan utama:

Menyimpan dan memutar ulang aliran event dalam jumlah besar secara real-time.

⚙️ Contoh Penggunaan

// producer
producer.send({ topic: 'user-events', messages: [{ value: 'UserRegistered' }] });

// consumer
consumer.subscribe({ topic: 'user-events' });
consumer.run({
  eachMessage: async ({ message }) => console.log(message.value.toString())
});

Kelebihan Kafka:

• Throughput tinggi dan penyimpanan event durable.

• Cocok untuk event sourcing, analitik, dan log streaming.

• Dapat di-replay kapan pun.

⚖️ 4. Perbandingan Lengkap

🧠 5. Kapan Digabung?

Dalam sistem berskala besar, ketiganya sering digunakan bersama:

📦 Contoh arsitektur:

User API → Queue (BullMQ / RabbitMQ) → Worker → Redis Lock → Database → Kafka

• Queue mengatur antrian pekerjaan agar beban server merata.

• Redis Lock memastikan hanya satu worker yang mengubah data tertentu dalam satu waktu.

• Kafka menyimpan jejak semua transaksi untuk analisis real-time.

Hasilnya: cepat, aman, dan konsisten.

🧩 Kesimpulan

🔑 Singkatnya:

• Gunakan Distributed Lock untuk memastikan hanya satu proses yang boleh mengubah data tertentu dalam satu waktu.

• Gunakan BullMQ/RabbitMQ untuk mengatur kapan dan bagaimana pekerjaan dijalankan.

• Gunakan Kafka untuk mencatat apa yang terjadi di seluruh sistem.