Software Architecture: The Hard Parts

Chapter 12. Transactional Sagas

Thursday, March 31, 16:55

Austen showed up at Logan’s office late on a windy Thursday afternoon. “Addison just sent me over here to ask you about some horror story?”

Logan stopped and looked up. “Is that a description of whatever crazy extreme sport you’re doing this weekend? What is it this time?”

“It’s late spring, so a bunch of us are going ice skating on the thawing lake. We’re wearing body suits, so it’s really a combination of skating and swimming. But that’s not what Addison meant at all. When I showed Addison my design for the Ticketing workflow, I was immediately instructed to come to you and tell you I’ve created a horror story.”

Logan laughed. “Oh, I see what’s going on—you stumbled into the Horror Story saga communication pattern. You designed a workflow with asynchronous communication, atomic transactionality, and choreography, right?”

“How did you know?”

“That’s the Horror Story saga pattern, or really, anti-pattern. There are eight generic saga patterns we start from, so it’s good to know what they are, because each has a different balance of trade-offs.”

The concept of a saga in architecture predates microservices, originally concerned with limiting the scope of database locks in early distributed architectures—the paper largely assumed to have coined the concept is from the Proceedings of the 1987 ACM conference. In his book Microservices Patterns (Manning Publications) and also outlined in the “Saga Pattern” section of his website, ...