Atasi Dual-Write Inconsistency: Outbox Pattern & CDC

Pukul 02.14 dini hari, alarm PagerDuty melengking tajam di ruang kendali operasional engineering. Sebuah insiden sistemik melumpuhkan alur transaksi: puluhan ribu checkout transaksi ecommerce tercatat sukses di database utama, tetapi payment notification service dan inventory management tidak menerima event sama sekali. Pelanggan mengalami pemotongan saldo, namun status pesanan di dasbor tetap menggantung pada status pembatalan otomatis. Investigasi pasca-insiden mengonfirmasi terjadinya fenomena klasik yang kerap menghantui arsitektur terdistribusi: Dual-Write Inconsistency.

Masalah ini tidak disebabkan oleh kesalahan logika sederhana, melainkan batasan mendasar dalam protokol jaringan. Ketika sebuah layanan microservice mencoba memperbarui database OLTP dan menerbitkan event ke Message Broker dalam satu alur eksekusi aplikasi, sistem dipaksa mempercayai dua dunia yang berbeda. Jika jaringan terputus atau application process mengalami crash mendadak persis setelah transaksi database berhasil dieksekusi namun sebelum pesan dikirim ke Kafka atau RabbitMQ, status data akan terfragmentasi selamanya.

Anatomi Kegagalan Dual-Write Naif

Pendekatan naif yang paling sering diimplementasikan oleh pengembang junior adalah menempatkan pemanggilan publisher message broker di dalam blok kode aplikasi setelah transaksi database di-commit. Secara konseptual, logika ini tampak logis:

1. Buka transaksi database.
2. Update baris data pesanan.
3. Commit transaksi database.
4. Kirim event OrderCreated ke Message Broker.

Namun, pada sistem skala besar, asumsi bahwa langkah 4 selalu berhasil adalah kekeliruan fatal. Gangguan jaringan mikro (network partition), kehabisan memori (out of memory), atau restart kontainer secara mendadak pada langkah 4 akan memicu ketidakselarasan data mendalam. Sebaliknya, jika urutan dibalik (mengirim pesan terlebih dahulu sebelum commit database), insiden phantom read atau penanganan event palsu oleh layanan konsumen akan terjadi apabila transaksi database kemudian memicu rollback.

Dalam tahapan perencanaan ketika arsitek melakukan evaluasi Event-Driven Architecture vs Modular Monolith, pemahaman atas batasan koordinasi terdistribusi ini menjadi penentu utama apakah arsitektur event-driven yang dibangun akan menjadi pilar efisiensi atau justru beban operasional tinggi.

Solusi Atomik: Transactional Outbox Pattern

Untuk memecahkan masalah ini tanpa protokol dua fase yang berat seperti 2PC (Two-Phase Commit), industri rekayasa perangkat lunak mengadopsi Transactional Outbox Pattern. Prinsip dasarnya mengembalikan jaminan konsistensi ke fitur terkuat dari relational database (RDBMS): ACID local transaction.

Daripada mencoba menghubungi Message Broker eksternal secara langsung dari layer aplikasi, aplikasi cukup menulis dua perubahan ke dalam satu database yang sama dalam satu transaksi ACID lokal:

1. Mengubah status data bisnis pada tabel utama (misalnya orders).
2. Menyimpan data event ke dalam tabel pembantu bernama outbox (INSERT INTO outbox...).

Karena kedua operasi ini dibungkus dalam satu transaksi database lokal, keduanya dijamin berhasil bersamaan atau gagal bersamaan (all-or-nothing). Tidak ada kondisi di mana data pesanan tersimpan tetapi record pada tabel outbox hilang.

BEGIN TRANSACTION;

UPDATE orders SET status = 'PAID' WHERE order_id = 'ORD-9921';

INSERT INTO outbox (id, aggregate_type, aggregate_id, type, payload, created_at) 
VALUES (
 gen_random_uuid(), 
 'Order', 
 'ORD-9921', 
 'OrderPaid', 
 '{"amount": 450000, "user_id": "USR-881"}', 
 NOW()
);

COMMIT;

Mengalirkan Event dengan CDC Debezium & Postgres WAL

Setelah data event aman berada di tabel outbox, tantangan berikutnya adalah memindahkan record tersebut ke Message Broker (seperti NATS, RabbitMQ, atau Apache Kafka). Metode lama menggunakan polling publisher—di mana proses latar belakang menjalankan query SELECT * FROM outbox WHERE processed = false setiap beberapa detik—terbukti menghancurkan performa database akibat query polling berulang dan lonjakan table locking.

Pendekatan modern 2026 mengombinasikan Transactional Outbox Pattern dengan Change Data Capture (CDC) berbasis engine seperti Debezium. CDC tidak lagi menyentuh tabel outbox dengan query SQL biasa, melainkan membaca langsung berkas Write-Ahead Logging (WAL) milik PostgreSQL di level storage engine.

Debezium Engine mengekstrak setiap perubahan byte pada disk yang berasal dari tabel outbox dan mengalirkannya langsung ke broker secara asinkron dengan latensi di bawah 10 milidetik, tanpa membebankan CPU core database utama untuk query SELECT.

• Latensi Event — Dual-Write Naif: Low (saat normal) | Polling Publisher: High (tergantung polling interval) | Transactional Outbox + CDC Debezium: Ultra Low (< 10ms via WAL Streaming)
• Overhead Database — Dual-Write Naif: Low | Polling Publisher: High (Spam query SQL & lock table) | Transactional Outbox + CDC Debezium: Zero Query Overhead (Membaca Disk WAL)
• Keandalan Data — Dual-Write Naif: Buruk (Risiko phantom/lost event) | Polling Publisher: Sedang (Rawan race condition) | Transactional Outbox + CDC Debezium: 99.999% Guaranteed (At-least-once)
• Resource Cost — Dual-Write Naif: Rendah | Polling Publisher: Tinggi (CPU Spike & I/O read disk) | Transactional Outbox + CDC Debezium: Terprediksi & Sangat Efisien

Strategi Deployment Stack CDC di Infrastruktur Cloud

Mengimplementasikan pipeline CDC berbasis Debezium, PostgreSQL WAL, dan NATS/RabbitMQ memerlukan perencanaan infrastruktur yang tepat. Kebutuhan I/O disk NVMe berkecepatan tinggi menjadi faktor penentu agar proses alir data WAL tidak terhambat (throttling) saat beban transaksi melonjak tinggi.

Untuk implementasi produksi enterprise, organisasi memiliki dua jalur arsitektural yang dapat disesuaikan dengan skala dan kapasitas tim:

1. Managed Cloud Ecosystem: Bagi tim enterprise yang menginginkan sistem siap pakai tanpa kerepotan pengelolaan operasi sysadmin atau cluster maintenance, opsi managed cloud via Frappe Cloud Partner menyediakan lingkungan terkelola penuh dengan SLA tinggi.
2. High-Performance Self-Hosted Cloud: Bagi Principal Architect yang membutuhkan akses root OS penuh, pengisolasian log WAL Postgres secara dedicated, serta penyesuaian parameter I/O disk NVMe tanpa biaya bandwidth egress yang melambung, membangun stack mandiri di atas infrastruktur Hostinger KVM VPS adalah opsi paling rasional secara ekonomi dan teknis. Dengan alokasi CPU dedicated dan NVMe storage cepat, engine Debezium dapat mengekstrak jutaan event WAL setiap jam dengan tingkat konsumsi resource yang sangat terkendali.

Penerapan alur event yang andal melalui outbox CDC ini menjadi pondasi mutlak ketika organisasi Anda memutuskan untuk menerapkan pola transaksi terdistribusi Saga dan 2PC guna mengoordinasikan rollback atau compensation transaction lintas mikroservis secara konsisten.

Kesimpulan & Rekomendasi Arsitektur

Mengabaikan konsistensi dual-write dalam arsitektur terdistribusi adalah bom waktu operasional yang dapat merusak kepercayaan pelanggan dan mengacaukan integritas keuangan enterprise. Kombinasi antara Transactional Outbox Pattern untuk aspek atomisitas lokal dan Change Data Capture (CDC) Debezium untuk pengiriman event berbasis WAL merupakan standar emas industri saat ini.

Dengan memindahkan beban pengiriman event dari alur eksekusi aplikasi ke layer streaming log database, Anda mendapatkan jaminan pengiriman event at-least-once dengan nol beban query tambahan pada database transaksi utama Anda.

Transparansi: Beberapa tautan di artikel ini adalah tautan afiliasi yang dapat memberikan komisi bagi kami tanpa biaya tambahan bagi Anda.