What doesn’t make sense:
- distributed transactions with REST services. REST services by definition are stateless, so they should not be participants in a transactional boundary that spans more than one service. Your user registration use case scenario makes sense, but the design with REST microservices to create User and Wallet data is not good.
What will give you headaches:
- EJBs with distributed transactions. It’s one of those things that work in theory but not in practice. Right now I’m trying to make a distributed transaction work for remote EJBs across JBoss EAP 6.3 instances. We’ve been talking to RedHat support for weeks, and it didn’t work yet.
- Two-phase commit solutions in general. I think the 2PC protocol is a great algorithm (many years ago I implemented it in C with RPC). It requires comprehensive fail recovery mechanisms, with retries, state repository, etc. All the complexity is hidden within the transaction framework (ex.: JBoss Arjuna). However, 2PC is not fail proof. There are situations the transaction simply can’t complete. Then you need to identify and fix database inconsistencies manually. It may happen once in a million transactions if you’re lucky, but it may happen once in every 100 transactions depending on your platform and scenario.
- Sagas (Compensating transactions). There’s the implementation overhead of creating the compensating operations, and the coordination mechanism to activate compensation at the end. But compensation is not fail proof either. You may still end up with inconsistencies (= some headache).
What’s probably the best alternative:
- Eventual consistency. Neither ACID-like distributed transactions nor compensating transactions are fail proof, and both may lead to inconsistencies. Eventual consistency is often better than “occasional inconsistency”. There are different design solutions, such as:
- You may create a more robust solution using asynchronous communication. In your scenario, when Bob registers, the API gateway could send a message to a NewUser queue, and right-away reply to the user saying “You’ll receive an email to confirm the account creation.” A queue consumer service could process the message, perform the database changes in a single transaction, and send the email to Bob to notify the account creation.
- The User microservice creates the user record and a wallet record in the same database. In this case, the wallet store in the User microservice is a replica of the master wallet store only visible to the Wallet microservice. There’s a data synchronization mechanism that is trigger-based or kicks in periodically to send data changes (e.g., new wallets) from the replica to the master, and vice-versa.
But what if you need synchronous responses?
- Remodel the microservices. If the solution with the queue doesn’t work because the service consumer needs a response right away, then I’d rather remodel the User and Wallet functionality to be collocated in the same service (or at least in the same VM to avoid distributed transactions). Yes, it’s a step farther from microservices and closer to a monolith, but will save you from some headache.