Your Read Model Doesn't Always Need a Database
The article discusses the concept of read models in event-sourced systems and challenges the assumption that a database is necessary for them. It argues that read models can be kept in memory, making them disposable and easily rebuildable from event data. This approach allows for flexibility in engineering choices regarding data storage and access patterns.
- ▪Read models in event-sourced systems do not need to be stored in a database.
- ▪They can be kept in memory and rebuilt from event data when necessary.
- ▪This method allows for multiple read models tailored to different queries without the constraints of traditional databases.
Opening excerpt (first ~120 words) tap to expand
Your Read Model Doesn't Always Need a Database¶ Sooner or later, every team building an event-sourced system runs into the same question: which database should we use for the read model? The textbook answer is reassuringly pragmatic. It depends. Pick the tool that fits the access pattern. Relational if you need joins and ad-hoc queries, document-oriented if your data is hierarchical, key-value if you mostly look things up by ID, a graph database for relationships, a spatial database for geodata, and so on. That advice is sound, and yet it quietly assumes something that nobody ever questions: that there has to be a database in the first place. There's one option that almost never makes it onto that list, and it's the one that turns the whole question on its head.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Eventsourcingdb.
Discussion
0 commentsMore from Eventsourcingdb
