NOTE
2.4 Best-Effort Notification
A notification pattern for external or loosely coupled systems using bounded retries, durable result lookup, and reconciliation instead of atomic cross-system commit.
This is a historical learning note and may contain outdated or incomplete understanding.
1. What Is Best-Effort Notification?
Best-effort notification is used when one system has already reached its authoritative local result and needs to inform another system, but the two systems cannot participate in one atomic transaction.
Examples include payment-result callbacks and notifications to external partners.
2. Typical Design
- the producer commits its own authoritative business state;
- it sends a notification to the receiver;
- failed delivery is retried with a defined policy, often with backoff and a finite retry horizon;
- the producer exposes a query API so the receiver can independently retrieve the authoritative result;
- monitoring or reconciliation handles cases that never converge automatically.
3. Difference from Reliable Event Delivery
Reliable event delivery usually treats successful downstream processing as an expected part of convergence and maintains durable retry state until the event is handled or explicitly dead-lettered.
Best-effort notification accepts looser coupling: notification delivery can ultimately fail, provided the receiver can query or reconcile the final state through another channel.
The exact boundary is an application contract, not a universal protocol definition.