LinkedIn·Monday, 10 August 2026·16d ago
Twenty years ago we thought the hard problem was distributed transactions. Today we think it's something else. Over two decades of working…
Atomikos
1,672 followers
Twenty years ago we thought the hard problem was distributed transactions.
Today we think it's something else.
Over two decades of working with distributed systems, one lesson keeps repeating itself.
Transactions aren't usually what customers struggle with.
Recovery is.
Not the happy path.
The day after the outage.
The moment a network fails halfway through a business operation.
The uncertainty after a timeout.
The question: "Did it commit or didn't it?"
Technology changes.
Frameworks change.
Architectures change.
That question hasn't.
It's still one of the hardest problems in distributed systems.
What's one lesson you've learned that hasn't changed, even as the technology around it has?
Cross-referenced
Related on the wire
What disappeared when Java moved away from application servers? More than many teams realized. Application servers bundled a lot together:…
A transaction manager does not prevent failures. It determines what should happen when they do. Imagine one business operation needs to do…
Most microservice transaction discussions start with technology. We think there is a better question to ask first: **What happens if this…
Reliable messaging has two sides. Sending reliably means making sure a business update and its outgoing message stay consistent. Receiving…
Most architecture diagrams show the happy path. But reliability is usually decided somewhere in the middle. Consider a simple workflow: -…
We didn't start by trying to replace application servers. We started by asking a different question. Years ago, many enterprise Java…