Databases are global, shared, mutable state

Databases are global, shared, mutable state. That’s the way it has been since the 1960s, and no amount of NoSQL has changed that. However, most self-respecting developers have got rid of mutable global variables in their code long ago. So why do we tolerate databases as they are?”

The above quote is from Martin Kleppmann’s post Turning the database inside-out with Apache Samza

This statement resonated with what I have seen as full stack developer. How much time would have been spent figuring out caching behavior of Hibernate and the whole Object Relational Mapping problem. It didn’t feel right and it makes sense now! And to make things worse some applications even relied on database triggers! That is mutable state on steroids.

To complicate the matters further most applications which are database centric, depends on the same database for integrating different subsystems of the application. Effectively the whole internal data model of a given subsystem/service is visible to every other subsysem/service. Over time this leads to a very fragile application architecture which is hard to maintain and modify.

The traditional approach to database and schema design is based on the fallacy that data must be written in the same form as it will be queried. Debates about normalization and denormalization (see“Many-to-One and Many-to-Many Relationships”) become largely irrelevant if you can translate data from a write-optimized event log to read-optimized application state: it is entirely reasonable to denormalize data in the read-optimized views, as the translation process gives you a mechanism for keeping it consistent with the event log.

The above quote is from his book Designing Data-Intensive Applications. This decoupling of how data is written from how data is queried is the whole idea behind Event Sourcing.

Written by Francois Fernando, a software craftsman and tinkerer.