duhengforever
commented
6 years ago I means that in saga pattern, a service must atomically update its database and publish an event , so in my opinion, a transactional message maybe a give a awesome complementation to simplify this process, what's your opinion? @cer @eventuateio @dartartem
cer
Hey，we have studied your framework in recent days and very appreciate your ideas and work on maintaining the consistency of transactions in the microservice architecture. Surprisingly, this is exactly what we are doing currently，we will add the new feature of transactional message in our project to ensure the eventual consistency of transaction in the microservice architecture.
In the process of realizing our ideas in rocketMQ, we also discovered that some issues have troubled us for a long time，so we did a lot of work in the following areas:
API abstraction In order to simplify the usage and shield the underlying implementation，we only provided several APIs for users，but users can use these APIs to complete various operations，ranging from traditional pub/sub scenarios to high volume real-time zero-loss tolerance transaction system scenarios.
Message reply mechanism As a zero-loss tolerance transaction system, our product naturally have a complete message reply mechanism that can be used in the event sourcing architecture or other architecture based on message. We also support strict ordering of messages, and can scale out gracefully.
Simplify the programming model We also made a lot of efforts to simplify the programming model，especially in transactional messaging.
According to my understanding，our transactional message feature maybe give a awesome complementation for the SAGA pattern, and at the same time, our product at least can provide you with some infrastructure like kafka .etc. But we also found some defects about saga：saga pattern made programming model is more complex，and in order to be reliable，a service must atomically update its database and publish an event, it cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker, so developers have to introduce other design patterns to achieve this. So could you give us some advice on combining saga patten with MQ, for simplify the programming model.