How Maximum‑Effort Notification Solves Distributed Transaction Challenges

1. Principle

The active side of a business activity (notification initiator) completes its local processing and then sends a message to the passive side (notification receiver). The message may be lost, but the active side retries to achieve eventual consistency, embodying the “maximum effort” characteristic.

The passive side exposes a callback interface to receive the notification, validates the payload, and executes its local business logic, closing the loop. Because the active side’s notification attempts are limited, it also provides a query‑compensation interface that the passive side can poll according to a schedule to recover lost messages.

Both the callback and the query interfaces must be idempotent to preserve data integrity and ensure final consistency.

2. Detailed Explanation

In a typical scenario such as integrating Alipay payment, the merchant system acts as the passive side while Alipay is the active side. The user initiates a payment, the merchant forwards the request to Alipay, and Alipay returns a pre‑payment result.

After Alipay completes the transfer, it sends a notification to the merchant. The merchant’s callback verifies the signature, extracts business parameters, and updates the order status (e.g., success, failure, refund).

Splitting synchronous business operations into asynchronous notifications can dramatically improve system flexibility and throughput.

If the passive side cannot process the notification promptly, it returns a failure code, prompting the active side to retry using a time‑decay strategy (e.g., 1 min, 5 min, 10 min, 30 min, 1 h, 2 h, 5 h, 10 h) until a configurable window expires. Manual intervention may reset the notification pointer when retries are exhausted.

3. Evaluation

Cost: Low, mainly the overhead of building the query and reconciliation systems.

Applicable scenarios: Low‑latency‑sensitive use cases such as recharge or transfer, especially across systems, services, or networks.

Used service patterns: Queryable operations, idempotent operations.

Characteristics:

The active side sends a notification (message loss allowed).

Retry rules follow a step‑wise time‑ladder; after N attempts, no further retries.

The active side offers a query interface for the passive side to recover lost messages.

Typical applications: payment channel notifications, bank transfer notifications, merchant notifications, real‑time or scheduled reconciliation.

4. Implementation Options

Scheduled task: a cron‑like job polls and sends notifications, persisting notification data; minimal external dependencies.

Scheduled message queue: notifications are triggered by delayed messages, also persisting data but requiring a highly available queue.

5. Optimization Suggestions

Add an external management system to handle failed notifications and allow manual re‑triggering.

Modularize the notification service, separating notification logic from business logic, and support configurable strategies per queue.

Ensure high availability of the notification service, possibly with a dedicated database and refined retry policies (e.g., time‑decay).

Enforce idempotency on both the active query interface and the passive callback interface.

Monitor memory and traffic; align producer and consumer rates, persist messages to survive restarts, and resume from the last offset.

6. Summary

The article provides a thorough walkthrough of the “Maximum‑Effort Notification” flexible solution for distributed transactions, illustrating its workflow, practical considerations, and optimization techniques, and sets the stage for future work on reliable message consistency.