Ask AI to Build a Trans­ac­tion Man­ag­er. Then Pull the Plug.

AI can gen­er­ate a trans­ac­tion man­ag­er in sec­onds. The real chal­lenge isn't get­ting trans­ac­tions to com­mit: it is re­cov­er­ing cor­rect­ly when the sys­tem crash­es at ex­act­ly the wrong mo­ment.

AI can gen­er­ate a trans­ac­tion man­ag­er in min­utes. But can it re­cov­er cor­rect­ly when the co­or­di­na­tor crash­es be­tween pre­pare and com­mit? That's where the real en­gi­neer­ing be­gins.

You can ask AI to build a trans­ac­tion man­ag­er.

It will hap­pi­ly do so.

The code com­piles. The demo works. Two data­bas­es com­mit to­geth­er. The pre­pare phase hap­pens. The com­mit phase hap­pens. Every­thing looks cor­rect.

Five min­utes lat­er you start won­der­ing:

"Why did any­one ever pay for trans­ac­tion man­age­ment soft­ware?"

Then the serv­er crash­es.

Now the real test be­gins.

The Hap­py Path Was Nev­er the Prod­uct

Let's say you trans­fer mon­ey be­tween two sys­tems.

One data­base deb­its Ac­count A.

Another data­base cred­its Ac­count B.

If every­thing works, then al­most any trans­ac­tion man­ag­er will get the job done. In­clud­ing one gen­er­at­ed by AI.

That's not the in­ter­est­ing part.

The in­ter­est­ing part is what hap­pens when the crash comes at ex­act­ly the wrong mo­ment.

Sup­pose both data­bas­es have pre­pared their changes.

The co­or­di­na­tor de­cides to com­mit.

Then the ma­chine dies.

One data­base com­mits.

The oth­er nev­er re­ceives the com­mit in­struc­tion.

Now what?

That ques­tion is the en­tire rea­son trans­ac­tion man­agers ex­ist.

The hap­py path was nev­er the prod­uct.

Re­cov­ery was.

Most Trans­ac­tion Bugs Hap­pen Months Later

The dan­ger­ous thing about trans­ac­tion bugs is that they don't show up im­me­di­ate­ly.

The demo pass­es.

The tests pass.

The code re­view pass­es.

Every­thing looks fine.

Then months lat­er a serv­er restarts dur­ing a de­ploy­ment.

Or a net­work con­nec­tion drops.

Or a data­base fails over.

Sud­den­ly a trans­ac­tion is left in doubt.

One sys­tem thinks it com­mit­ted.

Another thinks it rolled back.

You now have in­con­sis­tent data and no ob­vi­ous ex­pla­na­tion.

Those are the fail­ures that keep fi­nan­cial sys­tems awake at night.

The Hard Part Isn't Com­mit. It's Re­cov­ery.

A real trans­ac­tion man­ag­er has to an­swer ques­tions that rarely ap­pear in tu­to­ri­als:

• What hap­pens if the co­or­di­na­tor crash­es af­ter pre­pare?
• How does it re­cov­er pend­ing trans­ac­tions af­ter restart?
• How does it make sure re­cov­ery can run mul­ti­ple times with­out caus­ing du­pli­cates?
• What hap­pens if a re­source makes a uni­lat­er­al de­ci­sion?
• What hap­pens when dri­vers don't be­have ex­act­ly ac­cord­ing to the spec­i­fi­ca­tion?

Th­ese prob­lems are not the­o­ret­i­cal.

Every pro­duc­tion-grade trans­ac­tion man­ag­er con­tains years of lessons learned from solv­ing them.

The code of­ten looks more com­pli­cat­ed than nec­es­sary.

Usu­al­ly that's be­cause some­one al­ready learned the hard way why it wasn't.

Why Open Source Doesn't Change This

Our trans­ac­tion co­or­di­na­tor is open source.

You can in­spect every line.

We want peo­ple to do ex­act­ly that.

But read­ing the code is not the dif­fi­cult part.

Un­der­stand­ing why cer­tain pieces ex­ist is.

Many of the seem­ing­ly strange checks, re­cov­ery paths, and cor­ner-case han­dlers are there be­cause of real in­ci­dents in real pro­duc­tion sys­tems.

To a fresh read­er, some of them look re­dun­dant.

To some­one who has lived through a failed re­cov­ery at 2 a.m., they look es­sen­tial.

The Real Value

AI has made writ­ing code cheap­er than ever.

That's a re­mark­able achieve­ment.

But trans­ac­tion man­age­ment was nev­er about writ­ing code.

It was al­ways about guar­an­tee­ing an out­come.

The val­ue is not in co­or­di­nat­ing suc­cess­ful trans­ac­tions.

The val­ue is in re­cov­er­ing un­suc­cess­ful ones.

So by all means, ask AI to build a trans­ac­tion man­ag­er.

Then ask it what hap­pens when the co­or­di­na­tor crash­es be­tween pre­pare and com­mit.

The dis­tance be­tween those two an­swers is where the real en­gi­neer­ing be­gins.