In-Depth Analysis of the Raft Algorithm - Part One: The Origin of the Problem

Why Raft? The Painful Journey from Single-Node to Distributed Systems

1. Starting with a Single Node: Everything Was Simple

Imagine you’re developing a simple counter service:

// Single-machine version - works perfectly
type Counter struct {
    value int
    mu    sync.Mutex
}

func (c *Counter) Increment() {
    c.mu.Lock()
    c.value++
    c.mu.Unlock()
}

func (c *Counter) Get() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.value
}

The Beautiful World of Single-Node Systems:

Service Discovery and Registration

After adopting a microservices architecture in our system, interactions between modules shifted from intra-process communication to inter-process communication. These processes are not limited to a single instance, and when invoked, they often require identifying information—otherwise, the caller cannot initiate the request. Hereafter, the caller will be referred to as the client, and the called entity as the server.

The simplest approach is direct IP:Port connection. However, as mentioned earlier, multiple processes exist, making direct IP connections impractical. This requires centralized management by the business team, which is inconvenient. Therefore, we typically use components to decouple this process, known as registration centers. Common registration centers include: Zookeeper, ETCD, Consul, Nacos, etc. Typically, each server connects to the registry upon startup, registering its details—usually IP:Port along with metadata—for centralized management. When a client initiates a call, it retrieves a pool of service addresses and selects one via load balancing algorithms (often handled by the microservice framework). This constitutes the service registration and discovery mechanism.

DDD stands for Domain-Driven Design, born to enhance development efficiency in internet companies. Specifically, it employs a specialized description language to ensure PMs and RDs describe the same matter without one side favoring users and the other favoring technology.

Technically, it provides a series of concepts to guide us in applying this design within systems.

We’ll illustrate using the open-source version of coze’s code, then explore how to migrate it to microservices.

The most important thing in architectural design is to understand the positioning of the entire product system in the system. Only by figuring out the background behind the system can you make the best design and abstraction. Don’t be a translation machine for demand, first understand the essence behind the business and the original intention of the matter.

Comment system, when we go to the small, we are video comment system, when we go to the large, we are commenting platform, we can access various business forms.

Today we talk about bypass caching strategies.

Introduction to Concepts

Generally speaking we introduce caching in our business, which involves three ways of manipulating the database and caching:

• Read-through:
  1. application reads data.
  2. it checks Redis. a hit is returned.
  3. If there is no hit, check MySQL.
  4. Fetch the data from MySQL and write it to Redis.
  5. Return the data.
• Write through:
  1. The application updates the data.
  2. Code executes simultaneously (or in the same transaction):
     • Update the MySQL database.
     • Update (or invalidate) the corresponding cache in Redis.
• Bypass the cache:
  • Read operations: Use the “read-through” policy.
    • Cache Hit -> return cached data.
    • Cache Miss -> Read from DB, backfill Cache and return.
  • Write operation: first update DB, then delete (invalidate) cache.
    • This is the essence of the “bypass cache” strategy - “update the database first, then delete the cache”.

For read-through from the above introduction can also be seen that it is not used alone, and write-through, there is no middleware support for simultaneous operation of the database, so generally do not use, so the most daily use of the third way: bypass caching!

Core Principles

Start with the data.

What does this mean? Often, before transitioning to enterprise-level development, we consider a feature “complete” once it’s implemented and tested. But for an enterprise project, coding is just the beginning.

Because an API isn’t guaranteed to remain functional just because it passed initial tests. Continuous monitoring is essential—tracking success and failure rates, and modifying code based on business tolerance thresholds for these metrics.

Therefore, when selecting technologies, we must consider not only initial demo implementation and workflow validation but also whether the solution offers maintainability, scalability, and the ability to meet evolving data demands.