Maximum effort notification?

Maximum-effort notification actually I think local message tables can count as maximum-effort, transactional messages can count as maximum-effort. For the local message table, there will be background tasks to check the unfinished messages regularly, and then call the corresponding service. When a message fails to be called for many times, it can be recorded and then manual introduction or direct abandonment. That’s the best I can do. The same is true for transactional messages, which are truly normal when they are committed. If the subscriber does not consume or fails to consume, it will try again until it enters the dead-letter queue. In fact, this is the best effort. So the best effort notification really just indicates the idea of a flexible transaction: I’ve done my best to reach the final agreement of the transaction. This mode is applicable to time-insensitive services, such as SMS notification.

Solution for each scenario: 2PC and 3PC are highly consistent transactions, but there are still risks of data inconsistency, blocking, etc., and they can only be used at the database level. However, TCC is a compensatory transaction idea, which applies to a wider scope and is implemented at the business level, so it is more intrusive to the business. Each operation needs to implement the corresponding three methods. Local messages, transaction messages, and maximum effort notifications are all final consistent transactions and therefore suitable for some time-insensitive businesses.