What do you think?
Rate this book
Distributed Systems For Fun and Profit
60 pages, ebook
Published January 1, 2013
56 people are currently reading
1063 people want to read
About the author
Mikito Takada
5 books12 followersSoftware engineer @stripe; I write books and code.
http://mixu.net/
http://mixu.net/
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 58 reviews
December 6, 2016
As problem sizes increase you will reach a point where either the hardware upgrade that allows you to solve the problem on a single node does not exist, or becomes cost-prohibitive. At that point, I welcome you to the world of distributed systems.
This little book (and it is indeed little - only 60 pages) manages to pack an enormous amount of information about core distributed system concepts. Although it does not manage to cover everything (a task that is impossible in 600, let alone 60 pages), it offers concise and clear explanations and, even more importantly, links and references to many important works and papers on distributed systems. Highly recommended!
February 29, 2016
Маленькая (всего 60 страниц) и очень полезная книга. Просто и не сильно вдаваясь в научные подробности (подробности для интересующихся приведены в сносках) рассказывает о базовых вещах. Транзакциях, реплицировании, времени (векторные часы) и проблемах, что возникают при их использование. Для любителей, вроде меня, самое то.
January 13, 2019
This seems like an excellent introduction to recent ideas of distributed systems. It's largely a gentle exploration of the CAP theorem and the various kinds of systems that it allows, with mentions of real-world projects such as Cassandra and Dynamo. The section about CRDTs (lattices), and how they can allow convergence to a result regardless of order, was really illuminating.
I was surprised that it didn't cover consistent hashing, but the author is aware of the need: http://book.mixu.net/distsys/appendix...
The formatting of the Kindle version was perfect. I just had to browse to the site using the Kindle's browser and click on the download link to add it to my Kindle library. I'm grateful to the author for taking the time to write so clearly and for making it so accessible.
I was surprised that it didn't cover consistent hashing, but the author is aware of the need: http://book.mixu.net/distsys/appendix...
The formatting of the Kindle version was perfect. I just had to browse to the site using the Kindle's browser and click on the download link to add it to my Kindle library. I'm grateful to the author for taking the time to write so clearly and for making it so accessible.
November 6, 2021
Replication algorithms for fun and profit.
April 4, 2020
A very valuable, simple to understand, book. A simplified way to understand and gain an entry point to distributed systems.
I liked that the book was shared in github.
The language was simple.
My comment on the kindle version that the way the writer used to draw trees of item relations wasn’t clear to read in a mobile version.
I liked that the book was shared in github.
The language was simple.
My comment on the kindle version that the way the writer used to draw trees of item relations wasn’t clear to read in a mobile version.
December 31, 2013
I'm happy to say I now know a book I can point others to when they want a quick survey of key topics (not all, though) in distributed computing. Definitely worth a read if you are lacking in some area. I expect the coming year will see me reading many of the cited works.
January 5, 2015
Very good, but way too short, so many topics that deserve a lot more time don't get it. But at this price (free!) it's definitely worth your time.
Hopefully the author will be expanding it with additional topics and more in-depth treatment.
Hopefully the author will be expanding it with additional topics and more in-depth treatment.
April 26, 2019
Great intro book to distributed systems theory, with plenty of references to learn more once you're done.
July 21, 2021
Great introductory book
Read
August 1, 2025I think this is really good, and the parts I understood, I really liked. But I don't think it's really for beginners; there are so many complex terms and definitions here and not many examples of why and how they are used in real-world systems. I think it's probably intended more for people somewhat in the field of distributed systems (or at least on the fringe) who want to understand it better. Having experienced the problems that the common distributed systems algorithms solve would probably help it all make sense.
April 27, 2023
A great book about Distributed Systems. From the programmer's (not the mathematician's) point of view.
I love the approach to abstractions and modelling. The great rationale behind different models and abstraction levels. Difference between CAP and FLP impossibilities. Excellent conceptualisation, and great metaphors.
Great discussion about different types of consistency, strong, weak, client-centric, linear, sequential, and eventual, etc.
Love the philosophical debates, and clear definitions. Big plus for mentioning Nietzsche :)
I'm missing a chapter about byzantine fault-tolerant systems. Nevertheless, looking for more books written in such a concise, neat, and intuitive way.
My highlights:
- [[Good abstraction makes working with a system easier to understand, while capturing the factors that are relevant for a particular purpose]]
- [[Abstractions, fundamentally, are fake, but they make the world manageable]]
- [[Models that hide details are easier to understand, models that expose details are more performant]]
- [[Modelling reality requires removing as many details as possible to make it universally applicable, yet not too much to make it impractical]]
- The "C" in CAP theorem is "string consistency", but "consistency" is not a synonym for "strong consistency".
- The eventual consistency guarantee is as trivial as "people are eventually dead" — it means nothing unless we specify more constraints.
- Order is important because distributed systems that preserve order can be treated as a single computer.
- Time is a source of order, it allows us to define the order of events.
- Clocks allow us to synthesize an approximation of the same counter without communicating it directly.
- Casual clocks track only the relevant events (dependencies) that influenced the current state.
- Casual clocks are a generalisation of timestamps because timestamps are specific instance which assumes that everything was relevant.
- [[Assuming order is one way to reduce the space of possible executions and possible occurrences]]
- People can reason on ordered events, otherwise, there are too many permutations to consider.
- People tend to think in terms of total order. It's easier; however, distributed systems require thinking in terms of partial orders, where things happen concurrently.
- Depending on the system model: 1) the synchronous system model has a global clock; 2) The partially synchronous model has a local clock. 3) One cannot use clocks in the asynchronous system model.
- Using time has two benefits: define order across a system without communication and define timeouts.
- A vector clock is an extension of the Lamport clocks. It maintains distinct counters for each node and updates them on each internal event.
- The issue with vector clocks is that they can be quite large in large systems.
- Completeness is about maximizing detectability and is achieved by just not waiting forever.
- Accuracy is about minimalising false positives. String accuracy is possible only in synchronous systems and is achieved by setting hard time boundaries. In asynchronous systems only weak accuracy is possible.
- Weak completeness can be transformed into strong completeness by broadcasting information about the suspected process.
- Even the eventually weak failure detector allows for solving consensus problems.
- The easiest way to achieve total order is to nominate a single node (leader), which dictates the order of operations to other nodes. The downside is that the system is as slow as the slowest node, and the current leader is a bottleneck.
- [[Failure-detector is essential because it is not possible to tell whether a remote node has crashed or is experiencing high latency. Failed nodes can be ignored, but partitioned ones can not as they may cause divergence]]
- The distinction is crucial to achieving consistency because crashed nodes can be ignored (they won't diverge), but the partitioned can not be safely ignored as they cause divergence.
- Mutual exclusion, leader election, multicast and atomic broadcast are all instances of the more general problem of consensus
- [[Partition tolerance requires a method for breaking symmetry. The partitions MUST not be symmetric (equal). There must be a way to distinguish which one to follow and ignore the other]]. Otherwise, it is not possible to prevent divergence.
- Majority vote consensus requires an odd number of parties to achieve asymmetry—only one partition contains a majority.
- [[The majority consensus protocols are great because they prevent partitioning even in case of disagreement]]. The protocol may stop, but it will not diverge.
- [[CRDTs achieve eventual convergence by limiting a set of operations that are order-independent and insensitive to message duplication/re-delivery]]. Operations are associative, commutative, and idempotent. In mathematics, the structures are called join or meet semilattices.
- Inferences made within a monotonic framework once deductively valid, cannot be invalidated by new information. Inferences made within a non-monotonic framework can.
- [[Defeasible reasoning is non-monotonic logic because assertions made utilizing partial information can be invalidated by new knowledge]] For example, if we learn that Tweety is a bird, we'll assume that Tweety can fly; but if we later learn that Tweety is a penguin, then we'll have to revise our conclusion.
- [[Monotonic logic is great because we don't have to reconsider the validity of inferences]]. In other words, we don't have to re-compute data once we get new information. Once we know that Tweety is a bird, we can safely conclude that Tweety can fly, and nothing we learn can invalidate that conclusion.
- Calculating two numbers is monotonic. Aggregation is non-monotonic. The reason is that aggregation does not only calculate a sum but also asserts that it has seen all of the values. And the only way to assert that is via coordination across nodes.
I love the approach to abstractions and modelling. The great rationale behind different models and abstraction levels. Difference between CAP and FLP impossibilities. Excellent conceptualisation, and great metaphors.
Great discussion about different types of consistency, strong, weak, client-centric, linear, sequential, and eventual, etc.
Love the philosophical debates, and clear definitions. Big plus for mentioning Nietzsche :)
I'm missing a chapter about byzantine fault-tolerant systems. Nevertheless, looking for more books written in such a concise, neat, and intuitive way.
My highlights:
- [[Good abstraction makes working with a system easier to understand, while capturing the factors that are relevant for a particular purpose]]
- [[Abstractions, fundamentally, are fake, but they make the world manageable]]
- [[Models that hide details are easier to understand, models that expose details are more performant]]
- [[Modelling reality requires removing as many details as possible to make it universally applicable, yet not too much to make it impractical]]
- The "C" in CAP theorem is "string consistency", but "consistency" is not a synonym for "strong consistency".
- The eventual consistency guarantee is as trivial as "people are eventually dead" — it means nothing unless we specify more constraints.
- Order is important because distributed systems that preserve order can be treated as a single computer.
- Time is a source of order, it allows us to define the order of events.
- Clocks allow us to synthesize an approximation of the same counter without communicating it directly.
- Casual clocks track only the relevant events (dependencies) that influenced the current state.
- Casual clocks are a generalisation of timestamps because timestamps are specific instance which assumes that everything was relevant.
- [[Assuming order is one way to reduce the space of possible executions and possible occurrences]]
- People can reason on ordered events, otherwise, there are too many permutations to consider.
- People tend to think in terms of total order. It's easier; however, distributed systems require thinking in terms of partial orders, where things happen concurrently.
- Depending on the system model: 1) the synchronous system model has a global clock; 2) The partially synchronous model has a local clock. 3) One cannot use clocks in the asynchronous system model.
- Using time has two benefits: define order across a system without communication and define timeouts.
- A vector clock is an extension of the Lamport clocks. It maintains distinct counters for each node and updates them on each internal event.
- The issue with vector clocks is that they can be quite large in large systems.
- Completeness is about maximizing detectability and is achieved by just not waiting forever.
- Accuracy is about minimalising false positives. String accuracy is possible only in synchronous systems and is achieved by setting hard time boundaries. In asynchronous systems only weak accuracy is possible.
- Weak completeness can be transformed into strong completeness by broadcasting information about the suspected process.
- Even the eventually weak failure detector allows for solving consensus problems.
- The easiest way to achieve total order is to nominate a single node (leader), which dictates the order of operations to other nodes. The downside is that the system is as slow as the slowest node, and the current leader is a bottleneck.
- [[Failure-detector is essential because it is not possible to tell whether a remote node has crashed or is experiencing high latency. Failed nodes can be ignored, but partitioned ones can not as they may cause divergence]]
- The distinction is crucial to achieving consistency because crashed nodes can be ignored (they won't diverge), but the partitioned can not be safely ignored as they cause divergence.
- Mutual exclusion, leader election, multicast and atomic broadcast are all instances of the more general problem of consensus
- [[Partition tolerance requires a method for breaking symmetry. The partitions MUST not be symmetric (equal). There must be a way to distinguish which one to follow and ignore the other]]. Otherwise, it is not possible to prevent divergence.
- Majority vote consensus requires an odd number of parties to achieve asymmetry—only one partition contains a majority.
- [[The majority consensus protocols are great because they prevent partitioning even in case of disagreement]]. The protocol may stop, but it will not diverge.
- [[CRDTs achieve eventual convergence by limiting a set of operations that are order-independent and insensitive to message duplication/re-delivery]]. Operations are associative, commutative, and idempotent. In mathematics, the structures are called join or meet semilattices.
- Inferences made within a monotonic framework once deductively valid, cannot be invalidated by new information. Inferences made within a non-monotonic framework can.
- [[Defeasible reasoning is non-monotonic logic because assertions made utilizing partial information can be invalidated by new knowledge]] For example, if we learn that Tweety is a bird, we'll assume that Tweety can fly; but if we later learn that Tweety is a penguin, then we'll have to revise our conclusion.
- [[Monotonic logic is great because we don't have to reconsider the validity of inferences]]. In other words, we don't have to re-compute data once we get new information. Once we know that Tweety is a bird, we can safely conclude that Tweety can fly, and nothing we learn can invalidate that conclusion.
- Calculating two numbers is monotonic. Aggregation is non-monotonic. The reason is that aggregation does not only calculate a sum but also asserts that it has seen all of the values. And the only way to assert that is via coordination across nodes.
April 13, 2016
This neatly written book allows one to scratch the surface of vast field that is distributed systems and serves as gateway to other dense but canonical books on the theory of distributed systems and algorithms. The neatly organized chapters give you an idea of what are the important subdomains and concepts that one should be aware while designing and studying distributed systems. Brought back memories of the grad school distributed systems course for me. :)
March 25, 2014
The focus on replication keeps it slim, and this book manages to cover a lot of things it seems like one should know (Paxos, CAP, etc). My eyes glazed over towards the end (when he starts talking about convergent lattice data structures, Bloom query language, etc) but overall a pretty useful read.
January 24, 2019
Decent overview of distributed system's basics. My only complaint is that I feel like some parts could be explained in clearer terms.
Nevertheless, being only 60 pages long, it packs a lot of useful information.
Nevertheless, being only 60 pages long, it packs a lot of useful information.
July 14, 2015
Quick survey of some key topics involved.
June 20, 2016
What great about this book is that it contains the most relevant articles and the most influential papers on the subject and guide you through the high level overview so you know when to read one.
January 23, 2018
nice short introduction
August 7, 2024
This started as a fun book to read 6 years ago due to its relatively short amount of pages.
It came to me while writing a Golang distributed system with consensus that queried multiple services and discovered endpoints. It was an auxiliary service to an API gateway. While the service was short-lived and only lasted 1-2 years, it was a great learning experience, specifically for RAFT, HashiCorp's Serf, S.W.I.M, and the Lifeguard protocol. If you're interested in these ideas, you can read more about them in the papers and other books.
"Distributed Systems for Fun and Profit" is one of the best introductions to distributed systems. This very precise and concise explanation is enough to get you started in the problem space of distributed systems with consensus. It accurately states the challenges - applying the CAP theorem,
dealing with time and order of events, failure, failure detection, and especially monotonicity! Monotonicity is arguably the most important since it is critical for a distributed system with consensus leader election.
Of course, there's a Nietzsche quote in the book. 😅
“Every concept originates through our equating what is unequal. No leaf ever wholly equals another, and the concept "leaf" is formed through an arbitrary abstraction from these individual differences, through forgetting the distinctions; and now it gives rise to the idea that in nature there might be something besides the leaves which would be "leaf" - some kind of original form after which all leaves have been woven, marked, copied, colored, curled, and painted, but by unskilled hands, so that no copy turned out to be a correct, reliable, and faithful image of the original form.”
If we can turn a Nietzche quote from "On Truth and Lies in a Nonmoral Sense" from 1873 into a cornerstone in thinking about distributed systems, what else can't we do with philosophy? 🤣
It came to me while writing a Golang distributed system with consensus that queried multiple services and discovered endpoints. It was an auxiliary service to an API gateway. While the service was short-lived and only lasted 1-2 years, it was a great learning experience, specifically for RAFT, HashiCorp's Serf, S.W.I.M, and the Lifeguard protocol. If you're interested in these ideas, you can read more about them in the papers and other books.
"Distributed Systems for Fun and Profit" is one of the best introductions to distributed systems. This very precise and concise explanation is enough to get you started in the problem space of distributed systems with consensus. It accurately states the challenges - applying the CAP theorem,
dealing with time and order of events, failure, failure detection, and especially monotonicity! Monotonicity is arguably the most important since it is critical for a distributed system with consensus leader election.
Of course, there's a Nietzsche quote in the book. 😅
“Every concept originates through our equating what is unequal. No leaf ever wholly equals another, and the concept "leaf" is formed through an arbitrary abstraction from these individual differences, through forgetting the distinctions; and now it gives rise to the idea that in nature there might be something besides the leaves which would be "leaf" - some kind of original form after which all leaves have been woven, marked, copied, colored, curled, and painted, but by unskilled hands, so that no copy turned out to be a correct, reliable, and faithful image of the original form.”
If we can turn a Nietzche quote from "On Truth and Lies in a Nonmoral Sense" from 1873 into a cornerstone in thinking about distributed systems, what else can't we do with philosophy? 🤣
July 28, 2023
Good little primer to see what the lay of the land is. This "book" is not really going to teach you all of the details but will show you some categories on distributed algorithms and then send you on your way with a list of more things to learn. If you're new to the subject and you are self-learning, this is probably a pretty good place to start. You can read it on the official website too:
https://book.mixu.net/distsys/single-...
While it does not go over a lot of things, I have to give 5 stars because of the effort put in
https://book.mixu.net/distsys/single-...
While it does not go over a lot of things, I have to give 5 stars because of the effort put in
May 3, 2018
This book assembles the core of distributed systems papers and books. By reading only this book, despite the knowledge earned, it'll be scarce.
I'll spend some time reading references and appendices given by Takada.
I recommend it for every programmer who wish to learn or even dive into distributed systems.
I'll spend some time reading references and appendices given by Takada.
I recommend it for every programmer who wish to learn or even dive into distributed systems.
January 4, 2019
I was looking for a breakdown of distributed systems that cleared up some of the assumptions and jargon that has built up in my head over the years. This did some of that, but not as much as I had hoped. I'm still on the lookout for something that will give me a view of what is going on that can sink in as a good mental-model of how things are working that I can use quickly in real situations.
May 20, 2019
its a nice book that gives your idea about what to consider designing distributed systems. There were some sections that I had to leave the book and google some things in order to understand what writer is talking about.
May 7, 2020
Somehow user-friendly and dry at the same time. The author writes very clear descriptions of the concepts, so it's easy to follow and succinct. But it could certainly use some real-world examples to excite the imagination.
June 12, 2020
Not a very polished and well-organized book, but still provides a good overview of the topic and great lists for further reading. Given that the author makes this available for free, I give it three stars. Otherwise, I'd give it 2 stars.
June 7, 2022
Concise and comprehensive "cookbook" that reads easy and gives good overview on a lot of the issues that can occur when it comes to dealing with distributed systems.
I'd definitely keep it around for the reference purposes.
I'd definitely keep it around for the reference purposes.
January 31, 2025
A very concise introduction to distributed systems and is a good stepping stone for reading other materials on the subjects like papers or books. It also filled a lot of knowledge gaps i had from other materials on the same subject.
June 22, 2017
A good introduction to cluster computing. But some chapters lack clarity (4 & 5, on replication).
August 30, 2017
3.5 star. First book on DS. Quite challenging to cover topics of DS in a short book of 60 pages, so no surprise book covers more breadth than depth. Big thanks for free well formatted kindle version.
August 29, 2018
Knowledgeable quick read.
January 2, 2019
Definitely feels like a great overview of what a practitioner would need to know to understand distributed systems.
Displaying 1 - 30 of 58 reviews