Créer des consommateurs d’événements idempotents
Rendez les participants d’une saga en chorégraphie résistants aux événements en double ou reçus dans le désordre grâce aux consommateurs idempotents, au modèle Inbox et au modèle Outbox.
Créer des consommateurs d’événements idempotents est une leçon Microservices Communication Patterns (Saga, Circuit Breaker) gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Microservices Communication Patterns (Saga, Circuit Breaker), et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Microservices Communication Patterns (Saga, Circuit Breaker) comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
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
Questions Fréquemment Posées
La leçon « Créer des consommateurs d’événements idempotents » est-elle gratuite ?
Oui — le texte complet de « Créer des consommateurs d’événements idempotents » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Microservices Communication Patterns (Saga, Circuit Breaker), passe à CoddyKit PRO. Le cours Microservices Communication Patterns (Saga, Circuit Breaker) comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Créer des consommateurs d’événements idempotents » ?
Rendez les participants d’une saga en chorégraphie résistants aux événements en double ou reçus dans le désordre grâce aux consommateurs idempotents, au modèle Inbox et au modèle Outbox. Tu pratiques Microservices Communication Patterns (Saga, Circuit Breaker) avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Microservices Communication Patterns (Saga, Circuit Breaker) ?
Aucune expérience préalable n'est requise. Microservices Communication Patterns (Saga, Circuit Breaker) sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Créer des consommateurs d’événements idempotents » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Microservices Communication Patterns (Saga, Circuit Breaker) ?
Oui. Chaque leçon Microservices Communication Patterns (Saga, Circuit Breaker) inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Conception de sagas pilotées par les événements
- Bus d’événements et courtiers de messages
- Gestion de la compensation par les événements
- Créer des consommateurs d’événements idempotents