As a developer or engineer, there are generally few considerations you take into account regarding issues inside the core engineering tools that are treated usually as black boxes. In the end, if you were tasked with designing a solution that involves using some storage unit, what could you possibly do about a bug occurring deep inside Oracle or MongoDB? We usually deal with our technology choices, rather than trying to reinvent them. Yet, you might wonder: why do these technologies exist in such wide variety in the first place? Why are there more than five different philosophies for storing data, and dozens of products under each?
In his book Designing Data-Intensive Applications, Martin Kleppmann leads us along a path of pessimism, where we realize that everything an ordinary user takes for granted and assumes to be guaranteed is, in reality, vulnerable to crashes, performance anomalies, and all sorts of failure points including scenarios that sound like impossible of users attempting the exact same operation within the same fraction of a second. In addition to these, there are communication networks that fail and drop data, and rare hardware failures.
These tools built by the biggest corporations in human history; they might seem like black boxes to us. But as users, every one of us has encountered some unexpected behavior at some point in Gmail or Facebook, and as developers, all of us have faced completely unanticipated errors in some well known data solutions. Behind this reality lies the driving force behind the evolution of everything we see: everything is liable to fail or crash. After finishing the book, I am glad to be known for my pessimism at work (at the very least), and to recognize that such pessimism plays a significant role in technical progress within the field I work in.
It might come as a shock to some to learn that hard drives do not simply fail when a laptop running a traditional spinning-disk drive is dropped and the disk gets scratched; they also have an inherent lifespan. Even modern SSD technology, which began to proliferate over roughly the past twenty years, is estimated to have a lifespan of no more than ten years. Data centers replace all their servers, including storage drives, at periods ranging between 3 to 5 years. Would anyone expect to encounter an issue on LinkedIn due to a faulty hard drive in their servers in the United States? That might happen once in several million occurrences, but it remains unlikely under current standards. Taking a pessimistic view of the future, and aside from the evolutionary path of tech, the book inspired me to think of the future of all our tech stack; Facing some energy crisis or a major conflict, will the services we rely on remain operational as they are today?
In the first chapter, as part of his essential explanation of core system requirements for system designers, Kleppmann highlights: reliability and scalability, along with defining the concept of load in data systems, as well as performance and maintainability. Later in the book, each of these becomes a failure point through which we observe how system design has evolved as a response to that failure.
In a series of articles I intend to write, one of which was already completed when this piece was published, I will attempt to delve into other technologies using the same approach Kleppmann adopted. Kleppmann presents a specific problem to us, outlines the solution just as engineers proposed it years or decades ago until a beginner might assume it is the finest solution in the world, and then ruthlessly tears it down along one of the core dimensions: reliability, scalability, performance, or maintainability.
This article is merely an introduction to that perspective from Martin Kleppmann’s book regarding pessimism, points of failure and collapse, and evolution mirroring the way living organisms evolve. The upcoming articles will not necessarily be direct review and highlight of the book, but they will adopt its outlook to some degree, observing various angles of evolution, failure, and pessimism.
I would like to thank my friend Mohammed Salman, who recommended this book to me after a job interview last year in which I confused several general concepts regarding cluster-based storage systems. Taking my time to read this massive volume proved essential in absorbing its overarching philosophy over the course of an entire year.
Comments