Asynchronous Microservice Transaction Consistency via Message Queue
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems face challenges in ensuring data consistency and preventing duplicate transactions when processing transactions across multiple asynchronous computing services from different vendors.
Innovation Solution
A system that maintains data consistency between asynchronous microservices by using a transaction initiator to process transactions, a transaction executor to manage message queues, and a transaction processor to handle transaction messages, ensuring that only one update is stored in the second microservice database for duplicate transactions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If multiple asynchronous computing services process transactions independently, then processing speed and service autonomy are improved, but data consistency and duplicate transaction prevention deteriorate
Solution Approach 1:
The patent introduces a message queue as an intermediary component between the first computing service and the second computing service. Transaction messages are published to the message queue by the first service and consumed by the second service, enabling asynchronous communication while maintaining transaction tracking and consistency through the queue's inherent message management capabilities.
Solution Approach 2:
The patent implements preliminary action by having the first computing service pre-record transaction messages in a transaction table with status tracking before the second service processes them. The transaction message status is updated to indicate whether messages have been published to the message queue, ensuring that duplicate processing can be detected and prevented before it causes data inconsistency.
2Reliability
If transaction messages are tracked in a transaction table with status flags, then data consistency is improved, but system complexity increases
Solution Approach 1:
The transaction table serves multiple functions: it stores pending transaction messages, tracks their publication status to the message queue, and enables duplicate detection. This multi-functional approach consolidates what could be separate tracking mechanisms into a single unified structure, reducing overall system complexity while maintaining data consistency.
Solution Approach 2:
The system implements self-service through automatic duplicate detection and prevention. When the second computing service consumes a transaction message, it checks the transaction table for existing entries with matching identifiers. If a duplicate is detected, the service automatically skips processing, eliminating the need for complex external coordination mechanisms.
3Measurement precision
If duplicate transaction detection is implemented by checking transaction identifiers, then accuracy of transaction processing is improved, but processing time increases
Solution Approach 1:
The patent performs preliminary action by recording transaction messages in the transaction table with unique identifiers before they are processed by the second computing service. This pre-establishment of transaction records enables rapid duplicate detection through simple identifier comparison rather than complex transaction analysis, minimizing the time penalty for accuracy checks.
Solution Approach 2:
The patent replaces complex mechanical transaction verification mechanisms with a simpler information-based approach. Instead of comparing entire transaction contents or using complex consensus protocols, the system substitutes identifier-based lookup in the transaction table, which is computationally much cheaper and faster while maintaining sufficient accuracy for duplicate detection.
Data Source
AI summary
An example of communicating transaction data between a first service and a second service includes receiving transactions of first service, and processing the received transactions and storing the results in a database of the first service. For at least some of the received transactions, corresponding transaction messages are produced for processing by the second service, and tracking that each of the transaction messages is provided to a message queue. The transaction messages are received from the message queue and are processed using the second service, and the results are stored in a database of the second service. When there are duplicate transaction messages received from the message queue, the database of the second service only stores the results of one of the duplicate transaction messages.