Есть ли альтернатива Transactional Outbox pattern? В последнее время этот вопрос часто появляется в пабликах.
Говорят, что "Transactional Outbox" под названием "Local Messaging" впервые был опубликован в статье "BASE: An Acid Alternative: In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability" to ACM by ebay architect Dan Pritchett in 2008.
Как говорил Alexey Zimarev:
💬 "если же это первое сообщение в цепочке - то уже есть смысл смотреть на transactional outbox".
Имеется ввиду в случае отсутствия "Front-Door Queue".
Глубокое понимание этой проблемы и способов ее решения дается в главе "10.Messaging Endpoints :: Transactional Client" книги "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf.
А также эта тема затрагивается в главе "Chapter 9. Message Endpoints :: Transactional Client/Actor" книги "Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka" by Vaughn Vernon.
В приведенных главах подробно раскрывается утверждение of Alexey Zimarev.
Vaughn Vernon посвящает этой проблеме главу "8 Domain Events :: Spreading the News to Remote Bounded Contexts :: Messaging Infrastructure Consistency" книги "Implementing Domain-Driven Design".
Ссылки по теме:
🔷 "Subscribing to events :: Publishing events through the event bus :: Designing atomicity and resiliency when publishing to the event bus" by Cesar de la Torre, Bill Wagner, Mike Rousos;
🔷 "Subscribing to events :: Resiliently publishing to the event bus" by Cesar de la Torre, Bill Wagner, Mike Rousos;
🔷 "Transactional messaging" by Chris Richardson
🔷 "3.3.7 Transactional messaging" by Chris Richardson
🔷 "The Outbox Pattern" by Kamil Grzybek
🔷 "Achieving reliable dual writes in distributed systems" by Rishabh Gupta
🔷 "Transaction log mining"
🔷 "Transaction log tailing"
💬 "Both a sender and a receiver can be transactional. With a sender, the message isn’t “really” added to the channel until the sender commits the transaction. With a receiver, the message isn’t “really” removed from the channel until the receiver commits the transaction. A sender that uses explicit transactions can be used with a receiver that uses implicit transactions, and vise versa. A single channel might have a combination of implicitly and explicitly transactional senders; it could also have a combination of receivers.
With a transactional receiver, an application can receive a message without actually removing the message from the queue. At this point, if the application crashed, when it recovered, the message would still be on the queue; the message would not be lost. Having received the message, the application can then process it. Once the application is finished with the message and is certain it wants to consume it, the application commits the transaction, which (if successful) removes the message from the channel. At this point, if the application crashed, when it recovered, the message would no longer be on the channel, so the application had better truly be finished with the message.
How does controlling a messaging system’s transactions externally help an application coordinate several tasks? Here’s what the application would do in the scenarios described above:"
-- "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf, Chapter "Transactional Client"
#Microservices #DistributedSystems #Integration #DDD
Говорят, что "Transactional Outbox" под названием "Local Messaging" впервые был опубликован в статье "BASE: An Acid Alternative: In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability" to ACM by ebay architect Dan Pritchett in 2008.
Как говорил Alexey Zimarev:
💬 "если же это первое сообщение в цепочке - то уже есть смысл смотреть на transactional outbox".
Имеется ввиду в случае отсутствия "Front-Door Queue".
Глубокое понимание этой проблемы и способов ее решения дается в главе "10.Messaging Endpoints :: Transactional Client" книги "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf.
А также эта тема затрагивается в главе "Chapter 9. Message Endpoints :: Transactional Client/Actor" книги "Reactive Messaging Patterns with the Actor Model: Applications and Integration in Scala and Akka" by Vaughn Vernon.
В приведенных главах подробно раскрывается утверждение of Alexey Zimarev.
Vaughn Vernon посвящает этой проблеме главу "8 Domain Events :: Spreading the News to Remote Bounded Contexts :: Messaging Infrastructure Consistency" книги "Implementing Domain-Driven Design".
Ссылки по теме:
🔷 "Subscribing to events :: Publishing events through the event bus :: Designing atomicity and resiliency when publishing to the event bus" by Cesar de la Torre, Bill Wagner, Mike Rousos;
🔷 "Subscribing to events :: Resiliently publishing to the event bus" by Cesar de la Torre, Bill Wagner, Mike Rousos;
🔷 "Transactional messaging" by Chris Richardson
🔷 "3.3.7 Transactional messaging" by Chris Richardson
🔷 "The Outbox Pattern" by Kamil Grzybek
🔷 "Achieving reliable dual writes in distributed systems" by Rishabh Gupta
🔷 "Transaction log mining"
🔷 "Transaction log tailing"
💬 "Both a sender and a receiver can be transactional. With a sender, the message isn’t “really” added to the channel until the sender commits the transaction. With a receiver, the message isn’t “really” removed from the channel until the receiver commits the transaction. A sender that uses explicit transactions can be used with a receiver that uses implicit transactions, and vise versa. A single channel might have a combination of implicitly and explicitly transactional senders; it could also have a combination of receivers.
With a transactional receiver, an application can receive a message without actually removing the message from the queue. At this point, if the application crashed, when it recovered, the message would still be on the queue; the message would not be lost. Having received the message, the application can then process it. Once the application is finished with the message and is certain it wants to consume it, the application commits the transaction, which (if successful) removes the message from the channel. At this point, if the application crashed, when it recovered, the message would no longer be on the channel, so the application had better truly be finished with the message.
How does controlling a messaging system’s transactions externally help an application coordinate several tasks? Here’s what the application would do in the scenarios described above:"
-- "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions" by Gregor Hohpe, Bobby Woolf, Chapter "Transactional Client"
#Microservices #DistributedSystems #Integration #DDD