Microservices Communication Patterns (Saga, Circuit Breaker) · Pelajaran

Membangun Konsumen Peristiwa Idempoten

Jadikan peserta saga choreography aman dari peristiwa duplikat dan tidak berurutan menggunakan konsumen idempoten, pola inbox, dan pola outbox.

Membangun Konsumen Peristiwa Idempoten adalah pelajaran Microservices Communication Patterns (Saga, Circuit Breaker) gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Microservices Communication Patterns (Saga, Circuit Breaker), dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Microservices Communication Patterns (Saga, Circuit Breaker) mencakup 4 pelajaran total.

Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.

Events Get Redelivered

In a choreography saga, services react to events from a broker. Brokers deliver at least once, so the same event can arrive twice — and sometimes out of order. Naive handlers double-charge or double-ship.

The Goal: Idempotent Consumers

An idempotent consumer can process the same event repeatedly with no extra effect. This is essential for correctness in any event-driven saga.

Track Processed Event Ids

Give every event a unique id. Before handling, check whether you have already processed that id; if so, skip and acknowledge.

if (inbox.exists(event.id())) { ack(); return; }
handle(event);
inbox.save(event.id());
ack();

The Inbox Pattern

The inbox pattern stores processed event ids in a table inside the same database transaction as the business change. Insert + work commit together, so a redelivery is rejected by the unique constraint.

BEGIN;
  INSERT INTO inbox(event_id) VALUES (?); -- unique
  UPDATE orders SET status = 'PAID' WHERE id = ?;
COMMIT;

Why Atomicity Is Key

If you ack the event but crash before committing the business change, the work is lost. Doing both in one transaction guarantees they succeed or fail together.

The Dual-Write Problem

A participant must often update its DB and publish a new event. Doing these as two separate calls risks one succeeding and the other failing — the classic dual-write problem.

The Outbox Pattern

The outbox pattern solves it: write the outgoing event into an outbox table in the same transaction as the business change. A separate relay publishes from the outbox to the broker.

BEGIN;
  UPDATE orders SET status = 'SHIPPED' WHERE id = ?;
  INSERT INTO outbox(payload) VALUES (?);
COMMIT;

Relaying the Outbox

A poller or change-data-capture (CDC) tool like Debezium reads new outbox rows and publishes them, then marks them sent. Publishing is at-least-once, so downstream consumers must be idempotent too.

Handling Out-of-Order Events

Events may arrive out of order. Use version numbers or sequence ids and ignore stale events, or design handlers that converge to the correct state regardless of order.

if (event.version() <= current.version()) return; // stale

Compensations Must Be Idempotent Too

When a saga fails, compensating events also flow through the broker and can be redelivered. A compensation (e.g. refund) must itself be idempotent, or you refund twice.

Putting It Together

A robust choreography participant: consume via the inbox (dedup), do work and write the outbox in one transaction, relay the outbox to the broker, and make every handler — including compensations — idempotent.

Quick Check

Test your event-consumer knowledge.

Recap

You hardened choreography consumers:

Brokers deliver at-least-once, so events repeat and may reorder
Idempotent consumers process duplicates safely
The inbox pattern dedups within the business transaction
The outbox pattern solves the dual-write problem; a relay/CDC publishes it
Handle out-of-order events and make compensations idempotent too

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Membangun Konsumen Peristiwa Idempoten” gratis?

Ya — teks lengkap “Membangun Konsumen Peristiwa Idempoten” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Microservices Communication Patterns (Saga, Circuit Breaker), upgrade ke CoddyKit PRO. Kursus Microservices Communication Patterns (Saga, Circuit Breaker) mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Membangun Konsumen Peristiwa Idempoten”?

Jadikan peserta saga choreography aman dari peristiwa duplikat dan tidak berurutan menggunakan konsumen idempoten, pola inbox, dan pola outbox. Kamu berlatih Microservices Communication Patterns (Saga, Circuit Breaker) dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Microservices Communication Patterns (Saga, Circuit Breaker)?

Tidak diperlukan pengalaman sebelumnya. Microservices Communication Patterns (Saga, Circuit Breaker) di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.

Berapa lama pelajaran “Membangun Konsumen Peristiwa Idempoten” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Microservices Communication Patterns (Saga, Circuit Breaker) ini?

Ya. Setiap pelajaran Microservices Communication Patterns (Saga, Circuit Breaker) menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

← Kembali ke Microservices Communication Patterns (Saga, Circuit Breaker)