How Local Message Tables Solve Distributed Transaction Challenges

In micro‑service environments, distributed transactions are a common challenge; this article explains how to use a local message table mechanism to achieve eventual data consistency.

The local message table follows the Base theory: a distributed transaction is split into a local database transaction and an MQ message, allowing the two to be coordinated.

Implementation flow:

System A writes business data and inserts a notification message into a dedicated message table within the same database transaction, ensuring both succeed or fail together.

System A sends the message to a message broker (e.g., RocketMQ) and waits for a success response.

After the broker confirms delivery, System A updates the message status in the table to “sent”.

A scheduled task periodically scans the table for messages with status “pending” and retries sending them.

System B consumes the message, processes its own business logic, and must guarantee idempotency because messages may be delivered multiple times.

The approach offers several advantages:

Simple implementation: relies only on the database transaction mechanism and a message queue, avoiding complex distributed‑transaction frameworks.

Data‑consistency guarantee: even if some services fail, retry mechanisms ensure eventual consistency.

Broad compatibility: can be integrated with various technology stacks and business scenarios.

However, it also has drawbacks:

Additional overhead of maintaining the message table, increasing database load.

Reliance on the stability of the message queue; failures can cause message loss or delays.

Potential performance bottlenecks in high‑concurrency situations, requiring queue and service tuning.

Overall, the local message table solution suits distributed systems that require strong data consistency, can tolerate some latency, and have relatively simple business logic, but the choice should be based on specific requirements and architecture.