Transactional Outbox Pattern: Konsep & Implementasi

Pernah mengalami order berhasil tersimpan, tetapi notifikasi pelanggan tak pernah terkirim? Atau sebaliknya: pesan dikirim dua kali, saldo terpotong ganda? Masalah klasik ini muncul saat menulis data ke basis data dan menerbitkan event ke broker dilakukan terpisah. Di sinilah Transactional Outbox Pattern hadir: pola yang menjaga konsistensi data lintas batas layanan tanpa perlu dua fase commit yang rumit.

Apa itu Transactional Outbox Pattern?

Transactional Outbox Pattern adalah pendekatan untuk memastikan setiap perubahan data penting dipublikasikan sebagai event secara andal. Caranya, layanan menulis perubahan bisnis dan sebuah catatan di tabel “outbox” dalam satu transaksi database. Catatan outbox inilah yang nanti diambil dan dikirim ke message broker.

Pola ini menyelesaikan masalah dual-write: kegagalan sebagian antara penyimpanan data dan publikasi pesan. Alih-alih mengandalkan koordinasi terdistribusi, kita memanfaatkan atomicity pada database dan menerima eventual consistency pada sistem hilir.

Dibanding dua fase commit (2PC), pendekatan ini lebih sederhana, skalabel, dan ramah terhadap arsitektur microservices. Anda memperoleh at-least-once delivery yang dipadukan dengan konsumen idempoten untuk pengalaman mendekati exactly-once secara praktis.

Desain Arsitektur dan Alur Kerja

Pola ini memecah pengiriman event menjadi dua langkah yang aman dan terukur. Berikut alur intinya:

Aplikasi memproses permintaan (misalnya membuat order) dan melakukan INSERT/UPDATE data bisnis.
Dalam transaksi yang sama, aplikasi menulis satu baris ke tabel outbox berisi metadata event (ID, tipe, payload, status, timestamp).
Transaksi di-commit. Kini perubahan bisnis dan entri outbox tersimpan secara atomik.
Sebuah komponen terpisah—disebut relay atau publisher—membaca baris outbox yang belum terkirim.
Relay menerbitkan event ke broker (Kafka, RabbitMQ, dsb.), lalu menandai baris sebagai terkirim atau menghapusnya.

Dengan cara ini, risiko kehilangan event karena crash aplikasi setelah menulis data bisnis dapat dihilangkan. Jika publikasi gagal, baris outbox tetap ada dan dapat dicoba ulang (retry) menggunakan exponential backoff.

Terkait duplikasi, pola ini cenderung menghasilkan at-least-once. Oleh karena itu, gunakan kunci idempoten (misalnya event_id) dan logika deduplication di sisi konsumen agar efek bisnis tidak diproses ganda.

Implementasi Praktis di Basis Data dan Broker

Skema tabel outbox yang ringkas

Mulailah dengan satu tabel terdedikasi. Contoh kolom yang lazim:

event_id: UUID unik untuk deduplikasi lintas sistem.
aggregate_type dan aggregate_id: mengasosiasikan event dengan entitas bisnis.
event_type: jenis event (OrderCreated, PaymentCaptured).
payload: data terstruktur (JSON, Avro, Protobuf).
status atau published_at: penanda pengiriman.
created_at: urutan waktu untuk penjadwalan.

Indeks pada status/published_at dan created_at penting agar proses pembacaan efisien. Pertimbangkan partisi berdasarkan tanggal agar operasi pembersihan (TTL/retensi) mudah.

Polling vs Change Data Capture (CDC)

Ada dua cara umum mendorong event keluar dari outbox:

Polling: proses latar memindai baris yang belum terkirim secara periodik. Sederhana, fleksibel, dan cocok untuk beban sedang. Atur interval, batch size, dan locking (misalnya SELECT FOR UPDATE SKIP LOCKED) untuk menghindari bentrok.
CDC: gunakan log replikasi (mis. Debezium di atas MySQL/Postgres) untuk menangkap perubahan pada tabel outbox dan meneruskannya ke broker. Efisien, latensi rendah, dan bagus di skala besar, namun menambah kompleksitas operasional.

Untuk tim kecil, mulai dari polling sudah memadai. Saat throughput tumbuh, beralih ke CDC dapat memangkas beban database dan memperbaiki end-to-end latency.

Pengiriman, retry, dan deduplikasi

Retry berjenjang: gunakan exponential backoff dan batas maksimal percobaan. Setelah melewati ambang, kirim ke dead-letter queue agar tidak memblokir batch lain.
Idempoten di konsumen: simpan event_id yang pernah diproses (mis. di tabel processed_events) agar operasi turunannya (kredit saldo, update status) tidak dieksekusi dua kali.
Ordering: jika urutan penting per entitas, gunakan partition key berdasarkan aggregate_id di broker yang mendukung partisi (Kafka), atau pastikan relay memproses satu per satu per kunci.
Transaksi broker: pada Kafka, Anda bisa mengombinasikan idempotent producer dan transactional producer untuk menurunkan duplikasi di sisi topik.

Format payload dan skema

JSON mudah digunakan, tetapi pertimbangkan Avro/Protobuf untuk skala besar karena lebih hemat dan bisa dikelola dengan schema registry. Versi-kan skema event agar kompatibel mundur (backward compatible) dan mudahkan migrasi bertahap.

Praktik Terbaik, Tantangan, dan Observabilitas

Praktik terbaik

Transaksi kecil: tetap ringkas. Tulis data bisnis dan baris outbox, hindari logika berat dalam satu transaksi agar latensi tidak melonjak.
Pembersihan terjadwal: hapus atau arsipkan baris outbox yang sudah terkirim setelah melewati retensi tertentu. Gunakan partisi/TTL untuk efisiensi.
Pemisahan beban: jalankan relay di proses/worker terpisah. Skala horizontal saat throughput meningkat.
Backpressure: atur batas batch dan kecepatan kirim agar tidak membanjiri broker atau konsumen.
Keamanan data: hindari menyimpan PII sensitif mentah di payload. Gunakan enkripsi selektif atau tokenisasi.

Tantangan umum

Pertumbuhan tabel: tanpa retensi yang disiplin, ukuran tabel meledak dan memperlambat query. Terapkan arsitektur partisi dan compaction di broker jika perlu.
Duplikasi sulit dideteksi: di lintas-layanan, deduplikasi perlu disiplin. Wajibkan semua konsumen memeriksa event_id dan buat utilitas bersama.
Skema berubah: perubahan payload bisa mematahkan konsumen lama. Gunakan kebijakan kompatibilitas skema dan uji kontrak (consumer-driven contract).
Observabilitas end-to-end: tanpa pelacakan yang baik, insiden sulit diurai. Gunakan korelasi ID dari outbox hingga konsumen.

Observabilitas yang perlu disiapkan

Metode tracing: sisipkan trace/span ID ke payload untuk menghubungkan log aplikasi, outbox, relay, dan broker.
Metrix kunci: pantau outbox lag (jumlah baris menunggu kirim), publish latency, tingkat retry, dan ukuran payload rata-rata.
Alarm dini: buat alert saat DLQ bertambah, lag melewati ambang, atau rasio error produser meningkat.
Dashboard: tampilkan throughput per topik, distribusi durasi end-to-end, dan 95/99p latensi kirim.

Terakhir, siapkan prosedur replay: kemampuan menerbitkan ulang event dari outbox/arsip saat terjadi kegagalan hilir. Dokumentasikan langkah-langkahnya agar pemulihan insiden tidak panik-driven.

Dengan disiplin desain dan operasional, Transactional Outbox Pattern menjadi fondasi andal untuk arsitektur event-driven modern. Ia mengurangi risiko kehilangan pesan, menahan duplikasi, dan memberi jalur migrasi mulus dari monolit ke microservices tanpa mengorbankan integritas data.

Ringkasan

Pola outbox memindahkan kompleksitas dari “menulis ganda” ke mekanisme yang dapat diawasi dan diukur. Mulai sederhana dengan polling, jadikan payload terukur dan versi-kan, buat konsumen idempoten, lalu tingkatkan ke CDC saat skala menuntut. Dengan begitu, pipeline event Anda tetap akurat, efisien, dan siap tumbuh.