Saga vs Trans­ac­tion­al Call: Which One Should You Real­ly Use?

If you are build­ing mi­croser­vices, you have prob­a­bly heard of the Saga pat­tern

If you are build­ing mi­croser­vices, you have prob­a­bly heard of the Saga pat­tern. Maybe you are even us­ing it. After all, it is the de­fault an­swer you will find on Stack Over­flow and in most con­fer­ence talks when peo­ple ask: How do I man­age dis­trib­uted trans­ac­tions?

But here’s a bet­ter ques­tion: Do you re­al­ly need a Saga or are you just work­ing around a miss­ing fea­ture?

What the Saga Pat­tern Promis­es

At a high lev­el, Sa­gas break a large trans­ac­tion into small­er, lo­cal ones. If some­thing goes wrong mid-way, you call com­pen­sat­ing op­er­a­tions to undo the ear­li­er steps.

Sim­ple idea, right? Not quite.

In prac­tice, Sa­gas in­tro­duce se­ri­ous com­plex­i­ty:

• You need to de­fine undo log­ic for every op­er­a­tion.
• Undo may not even be pos­si­ble if oth­er process­es have al­ready act­ed on the data.
• Ser­vices are left in “doubt” un­til the saga com­pletes which com­pli­cates mon­i­tor­ing, re­port­ing, and test­ing. Most of the time, a ser­vice nev­er even knows if it will be com­pen­sat­ed for or not, mak­ing re­port­ing very hard.
• Fail­ures in the undo steps? Now you need re­tries for your com­pen­sa­tions, too.

By the time you are done wiring up your Saga, you have writ­ten half an or­ches­tra­tion en­gine and dou­ble the up­date log­ic that you would nor­mal­ly need for each ser­vice.

What if You Could Just... Roll Back?

The whole rea­son we reach for Sa­gas is be­cause we can’t roll back across ser­vices, right? But what if you could?

That’s what the Trans­ac­tion­al Call pat­tern en­ables: a true atom­ic, all-or-noth­ing op­er­a­tion that spans mul­ti­ple mi­croser­vices with roll­back sup­port built-in.

How Trans­ac­tion­al Call Works

With Atomikos and XA trans­ac­tions:

1. MS1 starts a new trans­ac­tion.
2. It calls MS2 and MS3, pass­ing a trans­ac­tion con­text.
3. Each ser­vice per­forms its work ten­ta­tive­ly, noth­ing is com­mit­ted yet.
4. If all calls suc­ceed, MS1 com­mits the trans­ac­tion, and every­thing be­comes fi­nal.
5. If any­thing fails, roll­back is au­to­mat­ic – every­where.

No com­pen­sat­ing log­ic. No cleanup jobs. No state ma­chines. Just con­sis­ten­cy.

When to Use What

Si­t­u­a­tion	Trans­ac­tion­al Call	Saga
In­ter­nal ser­vices only
Need strong con­sis­ten­cy
Oper­a­tions are nat­u­ral­ly un­doable
Avoid cus­tom roll­back log­ic

Sum­ma­ry

• Sa­gas are use­ful only when true roll­back isn’t pos­si­ble.
• Most of the time, you can get roll­back, with a Trans­ac­tion­al Call.
• Atomikos makes this easy in Spring Boot, JDBC, JMS, and be­yond.
• Don’t write com­pen­sa­tion log­ic if you don’t have to.

Keep it sim­ple. Use a trans­ac­tion.