Transaction Workflow:
- Validate Funds – Verify the sender’s account has sufficient balance.
- Withdraw Funds – Deduct the specified amount from the sender’s account.
- Transfer Funds – Credit the recipient’s account.
- Notify Parties – Send transaction receipts to both sender and recipient. If any step between 1 and 3 fails and retries are unsuccessful, the system must initiate a rollback to restore the previous state (e.g., refund the sender if the transfer fails).
Microservices Overview:
- Service A – Retrieves bank account details.
- Service B – Handles fund withdrawal.
- Service C – Manages fund transfer to the recipient.
- Service D – Sends transaction notifications.
Proposed AMQP-Based Architecture:
- A producer sends a message to the queue with a unique identifier (GUID).
- Service A consumes the message, validates the sender’s account, and publishes a new message if funds are sufficient.
- Service B picks up the message, withdraws funds, and publishes a follow-up message.
- Service C consumes the message, attempts the transfer, and publishes a rollback message if the transfer fails after retries.
- Service B listens for rollback messages and reverses the withdrawal if necessary.
Architectural Concern:
The current design introduces redundancy and complexity by chaining service operations through sequential message passing. Ideally, these operations should be encapsulated within a single transactional context to ensure atomicity and simplify rollback logic.
How can I employ AMQP/RabbitMq to satisfy these architectural concerns?
