Why Reliable Systems Need Two Kinds of Memory: Commit Logs and Context Feedback

The real problem is not building features. It is preserving intent.

What do distributed transactions in microservices and AI code generation have in common? At first glance, almost nothing. One belongs to backend architecture, the other to a future where software is partially written by models. But both collide with the same hard truth: creating something is easy compared with making sure it survives contact with reality.

A service can accept an order, reserve inventory, charge a card, and notify a kitchen. A model can generate a fullstack app with authentication, persistence, and external APIs. In both cases, the first draft is never the real challenge. The real challenge is what happens when one step fails, one assumption is wrong, or one component cannot see the full picture.

That is why the deepest connection between these two worlds is not technical style, but epistemology. Both are systems that act under partial knowledge. Both need a way to keep moving forward without pretending they are omniscient. And both become much more reliable when they stop relying on a single, magical moment of correctness and instead adopt two kinds of memory: one for commitments, one for feedback.

The systems that scale are not the ones that never fail. They are the ones that know how to remember what happened, learn from it, and continue safely.

The hidden cost of pretending everything can be atomic

The classic dream of software is atomicity: either everything works, or nothing does. That idea is elegant in a single database transaction, but it breaks down as soon as reality becomes distributed. Once an order service, payment service, and kitchen service each own their own data, there is no shared lock that can safely hold the whole world still.

Trying to force that old model into a new environment creates a brittle illusion of control. Distributed transactions promise global consistency, but they also couple availability to the weakest participant. If each service is highly available on its own, the combined workflow can still become fragile because every additional dependency multiplies the chances of failure. In practice, the system becomes less like a machine with gears and more like a row of dominoes balanced on thin wire.

A SAGA accepts this reality. It says: do not try to freeze the universe. Instead, split the work into forward steps and compensating steps, and make each step durable enough to resume later if needed. If the kitchen rejects an order after payment has already been authorized, the system does not panic. It executes the compensation path in reverse order and restores the world to a coherent state.

This is not a compromise in the shallow sense. It is a different philosophy of correctness. Correctness is no longer defined as instant global agreement. It is defined as eventual reconciliation with explicit recovery.

That philosophy matters far beyond microservices.

AI code generation has the same problem, only disguised as creativity

When an LLM generates code, it faces a similar constraint: it cannot see everything at once. It may produce a syntax error, a runtime bug, a broken integration, or an app that looks right but behaves wrong. The interesting part is that these failures are not just defects in the output. They are signals about the mismatch between the model’s internal guess and the external world.

The strongest systems do not ask the model to be perfect on the first pass. They create a feedback loop. Feed syntax errors back. Feed TypeScript errors back. Feed runtime errors back. Feed screenshots back. Generate tests, then use the test failures as new input. In other words, the model is not treated as a one-shot oracle. It is treated like a participant in a larger process that can observe, correct, and retry.

That is exactly what a SAGA does with services. A service should not be expected to guess the full truth of the enterprise. It should do its part, emit a durable signal, and let the next step respond. If the next step fails, the system needs a controlled way to compensate or retry. The architecture is not centered on perfection. It is centered on recoverable progress.

There is a subtle but profound lesson here. Whether the actor is a service or an LLM, the limitation is the same: local reasoning is valuable, but local reasoning is not the same as global truth. A service knows its own state, not the whole workflow. A model may know a plausible implementation, not the actual behavior of the app. The path to reliability is to acknowledge that gap and build a structure around it.

The unifying idea: durable intent plus corrective evidence

The deepest design pattern connecting these worlds is not simply “asynchronous messaging” or “LLM feedback.” It is this:

Reliable systems need a durable record of intent and a reliable stream of corrective evidence.

The durable record of intent says what the system is trying to accomplish. In a SAGA, that is the ordered set of business steps and their compensations. In code generation, it is the desired app structure, the constraints, the tests, and the external behaviors that must hold true. The corrective evidence says what actually happened: service failures, runtime errors, screenshots, rejected tickets, broken assumptions, missing imports.

Without durable intent, the system forgets its purpose. It reacts, but it does not progress. Without corrective evidence, the system keeps marching confidently in the wrong direction. The magic is not in choosing one or the other. It is in connecting them.

Think of it like navigation. The route plan is intent. The road conditions are feedback. A good driver does not keep recalculating the entire map from scratch every time traffic changes. Nor does a good driver follow the original plan blindly when a bridge is closed. The driver maintains the route as a commitment, then updates it with evidence from the road.

That is why asynchronous messaging and iterative model feedback feel so different on the surface yet solve the same coordination problem. They are both ways of making a system more than the sum of its isolated parts.

Why messaging and feedback are not just implementation details

It is tempting to treat message queues and error loops as plumbing. That is a mistake. They are not passive transport layers. They are the nervous system of the architecture.

In a SAGA, messaging does something profound. It decouples immediate availability from workflow continuity. A participant can be temporarily unavailable, but the message persists. The workflow does not vanish because one service is down. Later, when the service returns, the next step can still be triggered. The message becomes a memory of intent that outlives the transient failure.

In AI code generation, the same role is played by feedback artifacts. A screenshot is not just a debugging tool. It is a durable witness. A TypeScript error is not just a complaint. It is a constraint being restored to the system. A test failure is not merely a red light. It is encoded evidence that the current draft does not satisfy the requirements.

This is why the most capable code generation loops will likely evolve toward artifact driven correction. The model should not only generate code. It should also consume the observable consequences of that code. This is the same principle that makes event driven systems powerful: state is not inferred from wishful thinking, but reconstructed from signals.

The more complex the system, the less valuable “just try harder” becomes. What matters is whether the system can remember, observe, and compensate.

A practical framework: commit, observe, reconcile

If you want one mental model that applies to both distributed transactions and AI assisted software creation, use this three step loop:

1. Commit the intent in a durable form.
2. Observe the consequences through real signals.
3. Reconcile the mismatch with either correction or compensation.

This framework is powerful because it avoids two false extremes.

The first extreme is magical thinking: a single action will somehow produce the final truth. That is how people imagine both perfect distributed transactions and perfect code generation. The second extreme is chaos: abandon structure, because systems are too messy to coordinate. That leads to brittle engineering and endless manual cleanup.

The commit, observe, reconcile loop gives you discipline without denial. In a commerce workflow, committing means recording that an order is pending. Observing means waiting for payment confirmation, inventory reservation, and kitchen acknowledgement. Reconciling means either proceeding or compensating, such as refunding the card and marking the ticket rejected.

In code generation, committing means writing down the desired architecture, interfaces, and tests. Observing means executing the app, reading the errors, and inspecting the UI. Reconciling means fixing the code, changing the prompt, or importing an existing component instead of reinventing it.

This framing also explains why RAG for code reuse matters. If the model can search for relevant internal building blocks and import them instead of generating from scratch, it is not merely saving tokens. It is reducing the space of possible mistakes. It is shifting from invention toward controlled composition, which is exactly what good distributed systems do with services.

The deeper lesson: scale comes from bounded responsibility

There is a temptation in software to make each component do more and more, in the hope that fewer boundaries means fewer problems. But both SAGA design and iterative AI generation point in the opposite direction. The best systems scale by giving each part a bounded responsibility and then defining explicit rules for coordination.

A kitchen service should not know how payments are processed. A payment service should not know how menus are displayed. A code model should not be forced to invent every primitive from scratch. A test runner should not be asked to understand the full product vision. Each participant should do one thing well, then hand off evidence to the next participant.

That is not fragmentation. It is specialization plus coordination.

The old dream of software was that the strongest component would absorb everything else. The newer, more realistic dream is that each component will be strong enough to speak clearly and weak enough to fail safely. That combination is what makes complex systems evolvable.

We often say that microservices trade consistency for availability. But the real trade is richer than that. They trade implicit control for explicit coordination. Likewise, AI assisted development trades the fantasy of a flawless first draft for the discipline of iterative verification. In both cases, the payoff is not less complexity. It is manageable complexity.

Key Takeaways

• Do not confuse completion with correctness. A workflow or generated app can look finished while still being wrong. Build in explicit verification.
• Treat failure as data, not just interruption. Error messages, rejected states, screenshots, and test failures are all corrective evidence.
• Use durable intent. Record what the system is trying to do in a form that survives temporary failures.
• Design for compensation, not just success. If a later step fails, define how the system returns to a coherent state.
• Prefer bounded responsibility plus coordination. Let each service or tool do one job well, then connect them with durable handoffs.

The future belongs to systems that can change their mind safely

The most important insight shared by distributed transactions and AI code generation is not about technology. It is about how intelligence behaves under uncertainty.

No real system gets to know everything at once. So the winning strategy is not to demand perfect foresight. It is to create structures that can preserve intent, absorb feedback, and make correction routine instead of exceptional. That is what SAGA coordination does for business workflows. It is also what iterative, artifact driven generation must do for software creation.

A system that cannot revise itself is not robust, it is fragile. A system that can revise itself without losing track of its goal is powerful.

That reframes what reliability really means. Reliability is not the absence of failure. It is the ability to keep faith with an intention while reality keeps changing. The best systems, whether made of services or models, are the ones that can remember what they meant to do, learn what actually happened, and continue from there.