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.