Blog

iSAQB Software Architecture Gathering 2025​

Founder and CTO of the native web GmbH
Published on September 15, 2025

Why CRUD Is Equally Unsuitable for Fairy Tales and Businesses

An article by Golo Roden

A fairy tale in CRUD shows how technical language and technology collide because not everything can be represented using Create, Read, Updated, and Delete.

Once upon a time, there was a beautiful princess. Every year, she updated her age, and after a few years, she created the desire to discover the world and updated her location to the big, dark forest. However, the evil wolf created a meeting with her there and deleted her. The royal couple then updated their mood to “sad” and created a task for the hunter. He also updated his location to the big, dark forest, arranged a meeting with the wolf, deleted him – and then wanted to undelete the princess – but in CRUD-based systems, there is no undelete.

This means that instead, the story would have to be retold and changed so that the wolf no longer deletes the princess, but updates her isDeleted flag to true. Admittedly, this does not improve the fairy tale: it is already absurd, sounds rather strange, and is probably more likely to disturb people than to tell them an exciting story.

Why the fairy tale sounds so strange

However, this deliberately exaggerated summary is much more than just a joke. It illustrates what happens every day in many software projects: technical language and specialist language diverge. In the domain, concrete things with meaning happen —the wolf eats the princess, the hunter rescues her— while our systems reduce the same processes to the four basic technical operations of create, read, update, and delete (CRUD for short). Technically relevant verbs disappear behind generic processing steps.

However, this divergence has far-reaching consequences:

Loss of meaning: An update says nothing about what technical change has occurred, let alone why it happened. Was a contract extended or an account blocked? Was a payment reversed or a limit adjusted? Specialist departments do not recognize their world in CRUD language.

Loss of history: Overwriting states obscures traces. How did a state come about? What sequence led to an error or success? Audits, root cause analyses, and forecasts suffer when the past is not explicitly documented.

Misconceptions and workarounds: Where deletion is not technically permissible, soft deletes with isDeleted flags are created. Where corrections are necessary, an undelete is fantasized – or special paths are created that further dilute the semantics.

Communication breakdown between business and IT: When developers talk about updates while business users talk about cancellations, returns, or escalations, the likelihood of misunderstandings – and thus of wrong decisions – increases.

In short: CRUD is a technical abstraction that obscures the technical reality. It is convenient for tables, but it lacks meaning.

A different perspective: events instead of mere state changes

This is where event sourcing comes in, an alternative concept for data persistence. Instead of always saving the current state and regularly overwriting it with updates, event sourcing records the events that led to this state over time – in the language of the domain.

In the fairy tale, these would be events such as: “Princess entered forest,” “Wolf met princess,” “Wolf ate princess,”Hunter killed wolf,” “Princess was freed,” and so on. Each event is an immutable fact and remains permanently preserved. The current state (such as the princess still being alive or alive again, or her parents missing her) is a projection based on the sequence of these facts.

This approach offers tangible benefits:

Transparency and traceability: Every change can be traced back to a specific date and cause. You can check at any point in time why a system is the way it is today.

Clear semantics: Events have technical significance. Instead of generic updates, you see contract renewals, cancellations, role changes, incoming payments – exactly the terms that specialist departments think and speak in.

Corrections without falsifying history: Errors are not made “invisible” by retroactive manipulation, but are corrected by compensating events. This ensures the integrity of the data line.

Better analyses: Event streams map behavior over time. This is the basis for process analysis, anomaly detection, and predictions – and thus a solid foundation for applications in the field of artificial intelligence.

Decoupling and evolution: Events are excellent integration points. Other systems can dock without disrupting the core – a central component of modern, networked architectures.

For more details on how to design and develop software using this approach, visit cqrs.com. If you are particularly interested in the interaction with artificial intelligence – from event recording and projections to features for machine learning models – then we recommend reading eventsourcing.ai.

Why we stick with CRUD despite everything

The fact that CRUD is so widespread despite everything has less to do with technical suitability than with habit and tool history. Relational databases, OR mappers, and many frameworks favor a view primarily focused on the status quo. This is sufficient for simple data collection and efficient in the short term. However, with increasing complexity—multiple processes, cross-connections, regulatory requirements, analytical use—the advantage is lost: semantics disappear in the code, and the system becomes difficult to explain, test, and change.

The fairy tale analogy sums it up perfectly: we force a technical story into four technical verbs – and lose sight of the actual story in the process. The same thing happens in real systems, only more subtly. “Customer cancels order” becomes an update, “role is delegated” becomes an update, “risk is reassessed” becomes an update. In the end, a state remains – but the knowledge of how and why it came about is lost.

Your DSL and tool of choice will depend on your unique context. What type of diagram you want, where you want to display it, whether you need automation, whether you need multiple users, etc.

Event sourcing at the Software Architecture Gathering