NOTE
2.3 Reliable Messaging and Eventual Consistency
How a durable business change and a durable outgoing message are coupled so downstream services can converge through retries and idempotent consumption.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Goal
Reliable-message eventual consistency is used when a producer’s local business change must eventually cause work in another service, but holding a synchronous distributed transaction across both services is undesirable.
The central problem is the dual write: committing local database state and publishing a message must not leave a permanent gap between the two.
2. Typical Flow
- durably commit the local business change together with enough state to publish the event;
- publish the event to a durable broker;
- retry publication/delivery until acknowledged according to the design;
- consumers process the event idempotently;
- monitor poison messages and permanently failing workflows.
The result is usually at-least-once processing, not magical exactly-once business execution. Duplicate delivery must be expected.
3. Common Implementations
3.1 Transactional Outbox / Local Message Table
Write the business row and outbox row in one local database transaction, then asynchronously publish unsent outbox rows.
3.2 Broker Transactional Messages
Some brokers, such as RocketMQ, provide a transactional-message protocol that coordinates message visibility with a producer-side local transaction check.
4. Use Cases
Good fits include points, notifications, derived state, indexing, and cross-service updates where temporary inconsistency is acceptable but silently losing the event is not.