In distributed systems, data replication is one of the core design strategies. Its primary purpose is to improve system reliability, availability, performance, and fault tolerance by redundantly storing identical copies of data: 
 
 High Availability: If only a single node provides service, a single-node failure will render the service unavailable. By replicating data across multiple…
In the preceding chapters, we discussed how replication can prevent data loss caused by single points of failure, how partitioning can handle massive amounts of data, and how distributed transactions can ensure the atomicity of cross-node operations. 
 However, when we try to combine these mechanisms into a truly production-grade system that runs 24/7 with automatic fault tolerance, we…
So far, in the systems we have discussed, we have assumed that every machine stores all data. In the earlier chapter on replication, when the primary node receives a write request from a client, it saves the entire dataset both locally and on other replica nodes. This storage approach has the following problems: 
 
 Scalability : If data replication is done in a primary-backup manner, all…
So far, we have introduced replication and partitioning. Replication (including the consensus algorithms) improves system fault tolerance, while partitioning improves system scalability; these two techniques address the physical problems of data. In addition, data access in distributed systems often faces “logical problems” , which are solved by the transaction technology introduced in…
This is a story about “how to build reliable systems out of unreliable components.” 
 When you open your phone on a rainy night to order food delivery, the system behind it is undergoing complex collaboration: your request passes through a load balancer and gets routed to an instance of the order service; the order data is persisted to the master node of the database and…
In the evolution of modern software engineering, the transition from single-node applications to distributed architectures represents a critical watershed. This leap is not merely a matter of hardware stacking or code migration, but a profound transformation involving shifts in mindset, design philosophy, and even a renewed understanding of the laws of physics. 
 As the opening chapter of this…
In the previous chapter, we compared single-node systems with distributed systems. A single-node system communicates through shared memory, has a globally unique clock, and exhibits deterministic behavior when errors occur, making programming on such systems relatively straightforward. In contrast, a distributed system consists of multiple nodes that communicate via messages, which makes…
In distributed systems, multiple nodes work together. Client requests are sent to different nodes for processing, and these requests become events on individual nodes. As we will see, the system’s state is formed by executing these events one by one in a specific order . Therefore, the order of events is particularly important. Different nodes may see different sequences of events, which can…

 Motivation
 # 
 
 The Redis protocol has become the de facto standard for key-value storage protocols. Beyond the official Redis implementation, we have seen various compatible alternatives: 
 
 Valkey : The Linux Foundation’s official fork of Redis 7.2, licensed under BSD. It is the community’s true open-source alternative after Redis switched to SSPL, fully…
The ability to read source code is considered to be one of the underlying fundamental programmer skills, and the reason why this ability is important is that 
 
 inevitably need to read or take over other people’s projects. For example, researching an open source project, such as taking over a project from someone else. 
 Reading good project source code is one of the important…
Hi, I’m lichuang , also known as codedump (not “coredump”). I picked the name because I like digging into how code works under the hood — dumping its internals, so to speak. 
 I’m a software engineer based in Guangzhou, China (UTC+8), building distributed systems and infrastructure tools, mostly in Rust . I’m comfortable working asynchronously across time zones.…
Netizen name “codedump,” not “coredump.” I chose this name because I enjoy exploring the principles of code, hence the name “code dump.”
Areas of personal interest: 
 
 Distributed storage (hobbyist). 
 Systems programming (some knowledge). 
 Storage engines (passion). 
 Programming language implementation (amateur enthusiast). 
…