DDIA Chapter 1 (Book Log)
Joined a book club, and we started reading Designing Data Intensive Applications. I’ve wanted to join a book club for a while now and also had DDIA as part of the books I needed to read this year. 2 birds 1 stone ~ Joined a fantastic book club and also get to read DDIA as my first book.
“This book is a journey through both the principles and the practicalities of data systems, how you can use them to build data-intensive applications”, need any more nudge to pick up this book if you haven’t ?
Hopefully I’m committed to blogging about each chapter we cover and possible links.
Chapter 1: Reliable, Scalable & Maintainable Applications
Chapter 1 starts with a clear distinction between data-intensive and compute-intensive.
“Many applications today are data-intensive, as opposed to compute-intensive”. Apparently over the years, the amount of data needed to be stored, retrieved and processed has significantly increased. In a lot of the technologies we use today, there’s some sort of storage attached to it, databases, caches, search indexes & stream processing etc all store data.
Most data systems are a successful abstraction. They possess different characteristics suitable for the job at hand. In this video, Hannes Mühleisen goes through a summary of data systems in the last decades.
“In this chapter, we will start by exploring the fundamentals of what we are trying to achieve: reliable, scalable, and maintainable data systems.”
Let’s define Reliability, Scalability and Maintainability
Reliability, the system should continue to work correctly ( perfoming the correct function at the desired level of performance) even in the face of adversity. When something is reliable, this should typically mean trusting it’s correctness and it has good quality.
Scalability, as the system grows in volume, we should have reasonable ways of dealing with that growth. Software engineering at scale is so much different. You start to think about performance engineering, architecture, bottle necks, trade-offs etc.
Maintainability, over time many different people would work on the system, they should be able to work on it productively. I do think to build a system that is highly maintainable, a lot of design guidelines, coding principles have to be set. Working with systems that are a pain to maintain can be a productivity drainer. And this is often the case with systems that aren’t properly planned, no reviews, no future thoughts of what the system could grow into.
Links to look at:
How not to measure latency, we want to focus more on percentiles not mean.. cause mean is mean (pun intended).
https://www.youtube.com/watch?v=lJ8ydIuPFeU
Why Percentiles Don’t Work the Way You Think — Orange Matter (solarwinds.com)
Everything You Know About Latency Is Wrong — Brave New Geek
They’re a couple of more interesting links & articles you’d find in the book. Looking forward to more chapters and Book logs.
