Advanced

Idempotency vs Atomicity vs Exactly-Once (Practical)

Membedakan 3 konsep yang sering tertukar dan dampaknya ke desain pipeline production

50 min read Updated Mar 2026 By DataLearn Team

Mode Baca Pemula

Anggap ini sebagai "dasar anti-duplikasi dan anti-data rusak". Fokus baca:

Idempotent belum tentu atomic
Exactly-once biasanya properti end-to-end yang terbatas konteks
Bagaimana memilih desain yang cukup aman untuk bisnis

Kamus istilah: DE-GLOSSARY.md

Prasyarat Ringan

Paham pipeline bisa retry saat gagal
Tahu data duplicate bisa terjadi di ingestion/processing
Pernah lihat kasus partial write (setengah sukses)

Istilah Penting (3 Lapis)

Istilah: Idempotency

Definisi awam: Operasi diulang, hasil akhir tetap sama.

Definisi teknis: Properti operasi yang aman terhadap retry/rerun tanpa menambah side effect.

Contoh praktis: Upsert transaksi berdasarkan transaction_id, bukan insert buta.

Istilah: Atomicity

Definisi awam: Entah semua langkah berhasil, atau tidak ada yang jadi.

Definisi teknis: Eksekusi unit kerja sebagai transaksi indivisible (all-or-nothing).

Contoh praktis: Insert header dan detail order harus commit bersamaan.

Kenapa Sering Bingung?

Konsep	Menjawab Pertanyaan	Tidak Menjamin
Idempotency	Apa yang terjadi jika task diulang?	Konsistensi multi-step transaction
Atomicity	Apa yang terjadi jika gagal di tengah proses?	Duplikasi event dari upstream
Exactly-once	Bisakah efek business hanya sekali?	Selalu murah/sederhana di semua sistem

            Mitos Umum
            "Pakai Kafka = exactly-once otomatis" -> Salah, tetap tergantung sink, transaction boundary, dan semantics consumer.
"Task idempotent pasti aman" -> Belum tentu, bisa tetap meninggalkan partial side effect lintas sistem.
"Atomic di DB berarti end-to-end atomic" -> Salah, integrasi antar service tetap bisa partial.

        

Decision Framework: Pilih Strategi yang Realistis

Konteks Use Case	Strategi Minimum	Tambahan Jika Kritis
Analytics batch harian	At-least-once + dedup key + idempotent merge	Snapshot reconciliation harian
Near real-time dashboard	Micro-batch idempotent + watermark late data	Exactly-once sink bila tersedia
Financial ledger / billing	Atomic transaction + idempotency key	Outbox pattern + end-to-end reconciliation

Implementation Walkthrough

1) Idempotency Key Design

-- Good: stable key from business event
SELECT
  order_id,
  payment_id,
  event_time,
  md5(concat(order_id, '|', payment_id)) AS idempotency_key
FROM stg_payments;
        

2) Idempotent Upsert (Bukan Insert Buta)

-- Pseudo SQL merge
MERGE INTO fct_payments t
USING new_events s
ON t.idempotency_key = s.idempotency_key
WHEN MATCHED THEN
  UPDATE SET amount = s.amount, status = s.status
WHEN NOT MATCHED THEN
  INSERT (idempotency_key, order_id, amount, status)
  VALUES (s.idempotency_key, s.order_id, s.amount, s.status);
        

3) Atomicity Boundary yang Jelas

Tentukan boundary transaksi: jika satu proses menulis ke 2 storage berbeda, anggap tidak atomic kecuali ada mekanisme koordinasi (mis. outbox/inbox, saga compensation, atau 2PC).

4) Practical Exactly-Once via Outbox Pattern

-- Within one DB transaction:
-- 1) Update business table
-- 2) Insert event into outbox table
-- Later, relay service reads outbox and publishes safely with dedup id
        

Failure Modes & Anti-Patterns

            Yang Sering Bikin Incident
            No idempotency key: retry menghasilkan duplikasi permanen.
Non-deterministic transform: rerun hasil berbeda untuk input sama.
Cross-system partial commit: DB sukses, publish event gagal.
Dedup window terlalu pendek: duplicate lama lolos saat replay besar.
No reconciliation job: silent data loss tidak terdeteksi.

        

Production Readiness Checklist

            Checklist sebelum go-live
            Semua alur write punya idempotency key yang stabil.
Upsert/merge menggantikan insert buta untuk data replay-prone.
Atomicity boundary didokumentasikan per service/pipeline.
Outbox/inbox atau compensating action tersedia untuk cross-system write.
Replay test dilakukan minimal 2x run dengan input sama.
Metric dedup rate dan duplicate rate dimonitor.
Reconciliation job periodik aktif.

        

Exercise: Debug Duplicate Payment Incident

Kasus: payment gateway timeout, service retry 3x, data ledger terduplikasi.

Tugas:

Tentukan idempotency key yang tepat.
Desain ulang write path agar atomic di boundary yang memungkinkan.
Tulis query deteksi duplicate dan query remediation.
Definisikan 3 metric monitoring untuk mencegah kejadian ulang.

Quick Quiz

1. Pernyataan paling tepat tentang idempotency adalah?

A. Menjamin semua operasi multi-sistem atomic

B. Menjamin retry tidak mengubah hasil akhir secara salah

C. Sama dengan exactly-once end-to-end

D. Hanya relevan untuk streaming

2. Jika menulis ke DB dan publish ke queue, risiko utama apa?

A. Tidak ada risiko jika DB transactional

B. Partial success lintas sistem tanpa kompensasi

C. Selalu exactly-once

D. Hanya masalah performa