Cookie Consent by Free Privacy Policy Generator

[n]

read red book with boar if you are not junior

review on the masterpiece by Dr Martin Kleppmann - Designing Data-Intensive Applications

book review

As a developer, it is hard to follow the trends, even within your domain.
Path-to-production mapping, team cognitive load, thread modelling...
Backstage, Delta Lake, AWS Database Migration Service...
io-ts, Kotest, NestJS...

Some argue that it is an unavoidable burden for our generation.
Dr Kleppmann presents an alternative.
His point is simple, charming and hard to believe.
Vendors provide services and market the best application of them.
AWS, Azure, and Google Cloud have great shiny tools, true.
But when not to use the tools is left in the shade.
Writing it, having passed Azure Associate exam.
Martin focuses on the ideas and principles behind technologies.
Not cool marketing names in the mist of hype.

The author possesses vast knowledge.
But he does not stop with sharing them.
He realizes the might that technology brings.
He shows that he cares about the people.
This care wraps the book.
Dr Kleppmann starts and ends with a warning.
I believe he realized the value of his work.
It will allow thousands to cut corners.
It will help them dive into the material deeper and faster.

This book will be used again and again for another reason.
The width of the material makes a reference book.
If you look at the book from this perspective, it shines.
Definitions are plenty.
The explanations are simple because they leave marketing stuff outside.
Comparisons are surprising, even shocking.
In a streaming system, the joins are stored while the data is constantly changing as it is a stream.
This Martin compares the joins and streams to data and queries.
Here joins are stored, and data changes while it is reversed in a database. (p. 465)
Another fascinating facet of the books is exhaustiveness.
The author prepares readers to prove the point that distributed transactions are not flawless.
He analysed supporting concepts.
He first decompiles the blocks, to only build them later by the end of the second part.
Replication and partitioning, consistency, linearizability, total order broadcast, atomic commit and two-phase commit...

The work is complex.
It felt like experience in deployment, programming, database management, and a bunch of technologies is a must.
The book also contains almost no code.
That deprives a reader of the ability to gain skills and knowledge by following the steps.
On top of that, the book is simply long, 500+ pages.

There is, however, one thing that I personally missed.
The author praises stream-based data systems.
He proves that they deliver the same value as synchronous systems.
They also add properties that improve the design and development, like unifying reads and writes.
That was perfectly persuasive for me.
What the author should have mentioned was what it takes to persuade people to follow this approach?
Or, more importantly what it takes to build a strong experience in those systems?
But yeah, I am asking too much!

Send
Share
Send
Share