Construção de consumidores de eventos idempotentes
Torne os participantes de sagas de coreografia seguros contra eventos duplicados e fora de ordem usando consumidores idempotentes, o padrão inbox e o padrão outbox.
Construção de consumidores de eventos idempotentes é uma aula grátis de Microservices Communication Patterns (Saga, Circuit Breaker) no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Microservices Communication Patterns (Saga, Circuit Breaker), e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Microservices Communication Patterns (Saga, Circuit Breaker) inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
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; // staleCompensations 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
Aprenda Microservices Communication Patterns (Saga, Circuit Breaker) com um tutor de IA — grátis
Escreva e execute código real no seu navegador, obtenha ajuda instantânea de um tutor de IA 24/7 e continue de onde parou na web ou no app.
- Cursos
- 12
- Aulas
- 48
Perguntas Frequentes
A aula “Construção de consumidores de eventos idempotentes” é grátis?
Sim — o texto completo de “Construção de consumidores de eventos idempotentes” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Microservices Communication Patterns (Saga, Circuit Breaker), atualize para CoddyKit PRO. O curso de Microservices Communication Patterns (Saga, Circuit Breaker) inclui 4 aulas no total.
O que vou aprender em “Construção de consumidores de eventos idempotentes”?
Torne os participantes de sagas de coreografia seguros contra eventos duplicados e fora de ordem usando consumidores idempotentes, o padrão inbox e o padrão outbox. Você pratica Microservices Communication Patterns (Saga, Circuit Breaker) com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Microservices Communication Patterns (Saga, Circuit Breaker)?
Nenhuma experiência prévia é necessária. Microservices Communication Patterns (Saga, Circuit Breaker) no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Construção de consumidores de eventos idempotentes”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Microservices Communication Patterns (Saga, Circuit Breaker)?
Sim. Cada aula de Microservices Communication Patterns (Saga, Circuit Breaker) inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Conceção de Sagas orientadas por eventos
- Barramento de eventos e intermediários de mensagens
- Tratamento de compensações com eventos
- Construção de consumidores de eventos idempotentes