# Raft Raft is a consensus algorithm for fault-tolerant distributed systems in which servers agree on values and replicated state-machine commands. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Jetpack: Consensus Made Generally Fast (OSDI '26) DevFeed: [Jetpack: Consensus Made Generally Fast (OSDI '26)]() Original publisher: [Read original article]() Author: Murat (noreply@blogger.com) Published: 2026-09-12T05:36:27Z Content type: article Language: en Sources: [Metadata]() Topics: [Latency](), [systems](), [Replication](), [Raft](), [protocols](), [parallel](), [ordering](), [execution]() Tags: [architecture](), [consensus](), [consistency](), [distributed-consensus](), [execution](), [latency](), [livediscussion](), [network](), [ordering](), [parallel](), [paxos](), [raft](), [replication]() ### AI overview This paper review examines Jetpack, an add-on framework for existing leader-based consensus protocols. Jetpack runs a 1-RTT fast path alongside the original 2-RTT path, potentially reducing WAN commit latency, but its dual-log design duplicates network and replica processing and separates fast commitment from state-machine execution ordering. ### Source excerpt Aleksey and I are back to reading papers live. This paper, Jetpack(OSDI '26), attempts building a universal 1-RTT fast-path framework that bolts onto existing leader-based consensus protocols with minimal modification. Why would we want this? Classic consensus protocols like Raft, Paxos, or Zab require two round-trip times (2 RTT) to commit a command: one RTT from client to leader, and another to replicate across followers. The extra RTT matters a lot for WAN deployments, so fast-path protocols (such as Fast Paxos, EPaxos, or SwiftPaxos) reduce this to 1 RTT by bypassing leader serialization, but unfortunately they tightly couple the fast path to the core protocol design. Production systems cannot easily swap out their battle-tested bespoke consensus engines, but if there was an add on that helped with latency especially in WAN deployments, that would be useful. The good news is that Jetpack is truly an add-on portable deal. It provides a shim layer that runs two execution paths in parallel: a 1-RTT fast path and the original 2-RTT consensus path. When a client issues a command, it broadcasts the request concurrently to both paths. The fast path checks for key conflicts, and if none exist and a supermajority quorum ($\sim 3/4$ of nodes) issues a promise, this enables the command to fast-commit in 1 RTT. To guarantee agreement, original path proposers promise not to propose conflicting commands ahead of fast-committed ones. The bad news is that this design gets wasteful due to keeping two distinct logs (the fast-path log and the original-path log). The original consensus engine runs its full replication cycle in the background, ignoring the fast path replication of commands (because it is completely oblivious to the fast path replication in the name of bolt-on portability). So these commands travel in the network twice, and replicas process commands twice, introducing redundant work and extra CPU/network overhead. This dual-log architecture also creates a bigger gap ## 【kube-apiserver】选型收束与开放问题：排除树、Kine 与 events 分集群 DevFeed: [【kube-apiserver】选型收束与开放问题：排除树、Kine 与 events 分集群]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [Caching](), [etcd](), [SQL](), [MySQL](), [PostgreSQL](), [SQLite](), [Raft]() Tags: [apiserver](), [churn](), [distributed](), [errcompacted](), [etcd](), [events](), [exclusion-tree](), [kine](), [kubernetes](), [mysql](), [open-questions](), [postgresql](), [quota](), [raft](), [selection](), [sql](), [sqlite](), [storage](), [ttl](), [v1-30-3](), [watch-cache]() ### AI overview This concluding article presents a mechanism-based decision tree for diagnosing Kubernetes control-plane issues across kube-apiserver and etcd layers. It explains Kine's differing Watch semantics when using SQLite, PostgreSQL, or MySQL backends, discusses routing Kubernetes Events to a separate etcd cluster, and identifies open questions around watch-cache SLOs, compaction, linear reads, and Lease fencing. ### Source excerpt 用机制排除树收束何时查 apiserver 轴、何时穿透 etcd 轴、何时两轴联查；回收 etcd/13 写下的 apiserver 停损线；Kine SQL backend 的 Watch 语义差与 Jepsen 覆盖空白；events --etcd-servers-overrides 分集群运维；列出 watch cache SLO 联合模型、线性读期望与 Lease+fencing 全链路三个开放问题；以 ADR 语言关闭系列边界。 ## 【kube-apiserver】storage.Interface 与 etcd3：codec、prefix 与 CRUD 路径 DevFeed: [【kube-apiserver】storage.Interface 与 etcd3：codec、prefix 与 CRUD 路径]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [API](), [Encryption](), [Raft]() Tags: [api](), [apiserver](), [codec](), [crud](), [distributed](), [encryption](), [encryption-at-rest](), [etcd3](), [guaranteed-update](), [kubernetes](), [optimistic-concurrency](), [raft](), [rest](), [storage](), [v1-30-3]() ### AI overview This tutorial explains how kube-apiserver's storage.Interface integrates with the etcd3 backend in Kubernetes v1.30.3. It covers key prefixes, codec serialization, value transformation and encryption-at-rest boundaries, optimistic concurrency through GuaranteedUpdate and transactions, and the mapping from etcd3 watch streams to apiserver events. ### Source excerpt 拆解 kube-apiserver 的 storage.Interface 契约与 etcd3 实现：codec 序列化、pathPrefix/resourcePrefix、value.Transformer 加密边界、GuaranteedUpdate 乐观并发，以及 Watch 到 etcd3 的完整路径。版本锚定 Kubernetes v1.30.3 / etcd v3.5.33。 ## 【etcd】MVCC 数据模型：Revision、keyIndex 与 generation DevFeed: [【etcd】MVCC 数据模型：Revision、keyIndex 与 generation]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes]() Tags: [compaction](), [distributed](), [etcd](), [generation](), [keyindex](), [kubernetes](), [mvcc](), [raft](), [revision](), [treeindex](), [v3](), [v3-5](), [v3-5-33](), [watch]() ### AI overview This article analyzes etcd v3.5.33's MVCC data model through three concepts: globally ordered revisions, keyIndex generations that track key lifecycles, and the division of responsibilities between the in-memory treeIndex and the bbolt backend. It explains how these structures support historical Watch replay, transaction comparisons, compaction, and Kubernetes resourceVersion semantics, while distinguishing etcd revisions from Raft indexes. ### Source excerpt 拆解 etcd v3.5.33 的 Revision (main, sub) 全序、keyIndex/generation 生命周期与 treeIndex 分工；简要对照 v2 平面键空间，交代 MVCC 与 Watch/compaction 的语义基础。 ## 【etcd】写入路径深读：Txn、mod revision 与 quota/alarm DevFeed: [【etcd】写入路径深读：Txn、mod revision 与 quota/alarm]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Back end](), [Raft](), [Remote Procedure Call (RPC)](), [maintenance]() Tags: [alarm](), [apiserver](), [applied-index](), [apply](), [batch](), [bbolt](), [committed-index](), [compaction](), [defrag](), [distributed](), [errcompacted](), [etcd](), [follower](), [k8s](), [kubernetes](), [mod-revision](), [nospace](), [quota](), [revision](), [txn](), [v3-5](), [v3-5-33]() ### AI overview This tutorial explains the etcd v3.5.33 write path from gRPC requests through Raft proposal, quota checks, MVCC apply, and ModRevision assignment. It also describes proposal backpressure, backend quota accounting, and how a NOSPACE alarm blocks writes while reads, deletes, and maintenance operations can continue. ### Source excerpt 走读 etcd v3.5.33 写入路径：raftRequest 背压、Txn compare/mod 与 ModRevision 分配、backend quota 与 NOSPACE alarm 如何把集群推入只读。 ## 【etcd】bbolt 后端：mmap、batch 与单写者约束 DevFeed: [【etcd】bbolt 后端：mmap、batch 与单写者约束]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Databases](), [Raft]() Tags: [apply](), [backend](), [batch](), [bbolt](), [commit](), [distributed](), [etcd](), [kubernetes](), [mmap](), [mvcc](), [raft](), [v3-5](), [v3-5-33]() ### AI overview This article explains how etcd v3.5.33 maps its MVCC storage model onto the bbolt backend. It covers bucket layout, mmap behavior, buffered batch commits, read and write transaction concurrency, and how bbolt's single-writer constraint shapes apply and linearizable reads. ### Source excerpt 钉清 etcd v3.5.33 的 bbolt 后端：bucket 布局、mmap 预映射、100ms/10000 条 batch commit、ConcurrentReadTx 与单写者如何约束 MVCC 读写并发。 ## 【etcd】WAL 与快照：预写日志、crash recovery 与 commit vs applied DevFeed: [【etcd】WAL 与快照：预写日志、crash recovery 与 commit vs applied]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes]() Tags: [applied-index](), [committed-index](), [crash-recovery](), [distributed](), [etcd](), [kubernetes](), [latency](), [persistence](), [safety](), [snapshot](), [v3-5-33](), [wal]() ### AI overview This tutorial explains how etcd v3.5.33 uses WAL segments and Raft snapshots for persistence, log compaction, and crash recovery. It also describes how committed and applied indexes can diverge, causing Watch delays or extended not-ready periods even when Raft replication appears healthy. ### Source excerpt 拆解 etcd v3.5.33 的 WAL 段文件、Raft snapshot 触发与重启 recovery 顺序；钉清 committed index 与 applied index 分叉对排障与 K8s 控制面的含义。 ## 【etcd】Lease 与 KeepAlive：TTL、checkpoint 与 Leader 切换 DevFeed: [【etcd】Lease 与 KeepAlive：TTL、checkpoint 与 Leader 切换]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes](), [Remote Procedure Call (RPC)]() Tags: [api](), [checkpoint](), [client](), [concurrency](), [distributed](), [etcd](), [follower](), [k8s](), [keepalive](), [kubernetes](), [lease](), [lessor](), [primary](), [raft](), [ttl](), [v3](), [v3-5-33](), [watch]() ### AI overview This article explains etcd v3.5.33 lease behavior, focusing on the lessor's primary, demote, and promote roles, the KeepAlive renewal path that normally bypasses Raft, lease checkpointing, and TTL changes during leader transitions. It also discusses implications for Kubernetes Node Leases and distributed locks. ### Source excerpt 钉 etcd v3.5.33 lessor 的 primary/demote/promote、KeepAlive 不经 Raft 的 Renew 路径、LeaseCheckpoint 与 Promote 时 TTL 展期，以及 Leader 切换对 Node Lease 的排障落格。 ## 【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted DevFeed: [【etcd】Watch 机制：watchableStore、synced/unsynced 与 ErrCompacted]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Remote Procedure Call (RPC)](), [Kubernetes]() Tags: [apiserver](), [apply](), [compaction](), [distributed](), [errcompacted](), [etcd](), [io](), [k8s](), [kubernetes](), [lag](), [leader](), [lease](), [mvcc](), [notify](), [raft](), [range](), [restore](), [revision](), [rpc](), [v3-5](), [v3-5-33](), [watch](), [watchablestore]() ### AI overview This article examines the etcd v3.5.33 watchableStore implementation, including synced and unsynced watcher groups, victims caused by backpressure, Apply-time notification, historical synchronization, and the ErrCompacted client resynchronization boundary. It also discusses event ordering, follower watch progress, and interactions with Kubernetes apiserver watch caches. ### Source excerpt 钉 etcd v3.5.33 watchableStore 的 synced/unsynced/victims 三分法、Apply 后 notify 与历史追赶 syncWatchersLoop，以及 CompactRevision 触发 ErrCompacted 时的客户端重同步边界。 ## 【etcd】treeIndex 与 Apply 管道：propose -\> commit -\> apply DevFeed: [【etcd】treeIndex 与 Apply 管道：propose -\> commit -\> apply]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Back end]() Tags: [applied-index](), [apply](), [backend](), [bbolt](), [commit](), [compaction](), [distributed](), [etcd](), [index](), [kubernetes](), [mvcc](), [raft](), [range](), [recovery](), [revision](), [store](), [treeindex](), [txn](), [v3-5](), [wal](), [watch]() ### AI overview This tutorial explains the etcd v3.5.33 apply pipeline from Raft commit to MVCC application. It covers the separation between propose, commit, and apply; the roles of treeIndex and bbolt; consistent-index updates; watch notification timing; and troubleshooting committed-versus-applied lag. ### Source excerpt 走读 etcd v3.5.33 从 Raft commit 到 MVCC apply 的串行管道：treeIndex 与 bbolt 分工、consistent index、watchableStore 通知触发点，以及 committed/applied 分列排障。 ## 【etcd】单 Raft 组与服务器角色：Leader、Follower、Learner 与 request 路由 DevFeed: [【etcd】单 Raft 组与服务器角色：Leader、Follower、Learner 与 request 路由]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [gRPC]() Tags: [apiserver](), [apply](), [atomic](), [commit](), [compaction](), [distributed](), [etcd](), [etcdserver](), [follower](), [kubernetes](), [leader](), [learner](), [linearizable](), [raft](), [request](), [single-raft-group](), [v3](), [v3-5](), [v3-5-33](), [wal](), [watch]() ### AI overview This article explains how etcd v3.5.33 embeds a single Raft group, separates EtcdServer responsibilities from the Raft library, and routes requests across Leader, Follower, and Learner roles. It covers gRPC write forwarding, linearizable and serializable reads, and the handling of watch, lease, and mutating requests. ### Source excerpt 钉清 etcd v3.5.33 单 Raft 组拓扑、EtcdServer 与 go.etcd.io/raft/v3 边界、Leader/Follower/Learner 角色及 gRPC 写读路由；与 distributed/13 分工。 ## 【etcd】Txn 与并发语义：compare/mod 与 Jepsen 边界 DevFeed: [【etcd】Txn 与并发语义：compare/mod 与 Jepsen 边界]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [version](), [Raft](), [API]() Tags: [bug](), [compare](), [concurrency](), [distributed](), [etcd](), [jepsen](), [kubernetes](), [mvcc](), [raft](), [serializable](), [txn](), [v3-5](), [v3-5-33](), [version]() ### AI overview This article examines etcd v3.5.33 transaction semantics, including compare operations, nested transactions, MVCC visibility, ReadIndex behavior, and Raft-based atomic application. It distinguishes the design goals of the KV transaction path from the Lease session-lock path and carefully limits Jepsen evidence to etcd 3.4.3 rather than claiming an independent 3.5.33 rerun. ### Source excerpt 钉 etcd v3.5.33 Txn 的 compareToPath、MOD/CREATE/VERSION 比较与写 Txn 的 Raft 单槽 apply，并对照 Jepsen 3.4.3 的 strict-serializable 与 Lease 锁不安全子集。 ## 【etcd】选型收束与开放问题：排除树与系列边界关闭 DevFeed: [【etcd】选型收束与开放问题：排除树与系列边界关闭]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes]() Tags: [apiserver](), [backup](), [compaction](), [distributed](), [etcd](), [exclusion-tree](), [foundationdb](), [guide](), [k8s](), [kubernetes](), [lease](), [open-questions](), [raft](), [selection](), [tikv](), [v3](), [v3-5-33](), [zookeeper]() ### AI overview This concluding article presents a mechanism-based decision tree for deciding when to retain etcd and when to migrate to TiKV or FoundationDB. It defines etcd's fit for small data sets with Watch and Lease dependencies, identifies disqualifying conditions such as quota pressure, sharding needs, cross-key transactions, Watch backpressure, and insufficient operational capacity, and clarifies the boundaries between related article series. ### Source excerpt 用机制排除树收束何时该留 etcd、何时迁 TiKV/FDB/ZK；回收 distributed/39、tikv-htap/18、foundationdb/18 的 etcd 叶；列出 Watch 背压、Lease+fencing、quota 迁移等开放问题；以 ADR 语言关闭续作边界。 ## 【etcd】读路径与一致性：ReadIndex、Serializable 与 Lease read DevFeed: [【etcd】读路径与一致性：ReadIndex、Serializable 与 Lease read]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [consensus algorithm](), [Kubernetes]() Tags: [consistency](), [distributed](), [etcd](), [follower](), [k8s](), [keepalive](), [kubernetes](), [lease](), [linearizable](), [raft](), [readindex](), [resourceversion](), [revision](), [serializable](), [ttl](), [v3-5](), [v3-5-33]() ### AI overview This tutorial explains read consistency in etcd v3.5.33. It distinguishes default linearizable reads using ReadIndex, local Serializable reads that may be stale on followers, and Lease RPC reads handled by the leader outside the Raft log. It also discusses leader changes, apply-index waiting, follower forwarding, MVCC history reads, and implications for Kubernetes apiserver clients. ### Source excerpt 分列 etcd v3.5.33 三种读语义：默认线性一致读的 ReadIndex 循环、Serializable 本地读、Raft ReadOnlyLeaseBased 与不经 Raft 的 Lease 路径；follower 读风险与 K8s 期望。 ## 【etcd】Compaction、Defrag 与容量：quota、alarm 与 SLO DevFeed: [【etcd】Compaction、Defrag 与容量：quota、alarm 与 SLO]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-26T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes]() Tags: [alarm](), [bbolt](), [benchmark](), [compaction](), [defrag](), [distributed](), [errcompacted](), [etcd](), [follower](), [kubernetes](), [lag](), [leader](), [mvcc](), [nospace](), [performance](), [quota](), [raft](), [resourceversion](), [v3](), [v3-5](), [v3-5-33](), [watch]() ### AI overview This technical article explains how etcd v3.5.33 compaction, defragmentation, quota handling, and the NOSPACE alarm interact. It distinguishes revision-history removal from bbolt file reclamation, describes periodic and revision-based auto-compaction, and connects retention, quota, defrag pauses, and Watch or Kubernetes control-plane behavior to operational SLOs. ### Source excerpt 钉 etcd v3.5.33 MVCC compaction 与 bbolt defrag 的分工、auto-compaction 保留窗口、quota-backend-bytes 与 NOSPACE alarm 写入门，以及 ErrCompacted 如何写进 Watch SLO。 ## Multi-region high availability for Kafka workloads with a single Stretch Cluster DevFeed: [Multi-region high availability for Kafka workloads with a single Stretch Cluster]() Original publisher: [Read original article]() Author: David Yu Published: 2026-08-11T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Kafka](), [Kubernetes](), [Availability](), [Replication](), [Raft](), [Resilience](), [stream-processing]() Tags: [clusters](), [k8s](), [kafka](), [raft](), [release](), [replication](), [resilience](), [stream-processing]() ### AI overview Redpanda Operator 26.2 introduces generally available Stretch Clusters, allowing one logical Redpanda cluster to span multiple Kubernetes clusters and regions. The release provides synchronous replication with Raft-based automatic failover, safer broker rolling restarts, Redpanda Connect pipelines as Kubernetes resources, and Gateway API support for Redpanda Console. ### Source excerpt Redpanda Operator 26.2 brings GA Stretch Clusters for multi-region replication, Redpanda Connect pipelines as K8s resources, Gateway API support, and safer rolling restarts. ## 【TiKV / HTAP 内核】Region - Multi-Raft - PD - Percolator - TiFlash DevFeed: [【TiKV / HTAP 内核】Region - Multi-Raft - PD - Percolator - TiFlash]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-07-16T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Raft](), [rocksdb](), [etcd](), [SQL](), [CockroachDB](), [Databases]() Tags: [database](), [distributed](), [distributed-kv](), [etcd](), [htap](), [learner](), [multi-raft](), [pd](), [percolator](), [raft](), [range](), [region](), [rocksdb](), [snapshot](), [split](), [sql](), [storage](), [tidb](), [tiflash](), [tikv](), [tso]() ### AI overview This article series explains TiKV 7.x/8.x internals through Region modeling, Multi-Raft replication, raftstore apply, RocksDB column families, PD and TSO scheduling, Percolator transactions, coprocessor boundaries, and TiFlash Learner freshness. It also compares selected aspects with etcd and CockroachDB. ### Source excerpt 补齐 RocksDB 单 Region、Raft 协议与 HTAP 范式之间的工程链路：以 TiKV 7.x/8.x 拆解 Region、Multi-Raft、raftstore、PD/TSO 与 Percolator 事务，并以 TiFlash Learner 收束新鲜度；CockroachDB 对照与选型。 ## Coinbase trading outage exposed single-availability-zone dependency DevFeed: [Coinbase trading outage exposed single-availability-zone dependency]() Original publisher: [Read original article]() Author: Gergely Orosz Published: 2026-06-23T16:30:59Z Content type: opinion Language: en Sources: [The Pragmatic Engineer]() Topics: [coinbase](), [reliability](), [Amazon Web Services](), [Availability](), [Raft](), [Latency]() Tags: [availability](), [aws](), [coinbase](), [latency](), [outage](), [raft](), [reliability]() ### AI overview A commentary article examines a nearly 10-hour Coinbase trading outage that coincided with a regional AWS outage. It says Coinbase confirmed that its matching engine depended on a single availability zone, a design chosen to avoid inter-zone latency for its Raft-based replicated cluster. ### Source excerpt Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from this past The Pulse issue. Full subscribers received the ## Scalable Leader Leases for Distributed SQL Databases: CockroachDB at SIGMOD 2026 DevFeed: [Scalable Leader Leases for Distributed SQL Databases: CockroachDB at SIGMOD 2026]() Original publisher: [Read original article]() Author: Rebecca Taft Published: 2026-05-26T00:00:00Z Content type: release Language: en Sources: [Cockroach Labs]() Topics: [CockroachDB](), [distributed-systems](), [Databases](), [Cockroach Labs](), [SQL](), [Raft](), [systems](), [health checks]() Tags: [2026](), [cockroach-labs](), [cockroachdb](), [consensus](), [distributed](), [paper](), [sql]() ### AI overview Cockroach Labs announces a SIGMOD 2026 paper on scalable leader leases for multi-consensus groups in CockroachDB. The paper addresses lease-management overhead in distributed SQL databases, where coordinating leases across very large numbers of replicated data ranges can consume CPU and slow recovery from failures. ### Source excerpt We are pleased to announce that Cockroach Labs has a new paper appearing at SIGMOD 2026: Scalable Leader Leases For Multi Consensus Groups in CockroachDB. ## Cloud Topics: Level Zero garbage collection DevFeed: [Cloud Topics: Level Zero garbage collection]() Original publisher: [Read original article]() Author: Oren Leiman Published: 2026-05-19T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Cloud](), [distributed-systems](), [Raft](), [systems]() Tags: [architecture](), [atomic](), [cloud](), [distributed-systems](), [engineering](), [garbage-collection](), [raft](), [storage](), [systems]() ### AI overview This article explains how Redpanda Cloud Topics safely garbage-collects temporary Level Zero (L0) objects after their data has been reorganized into Level One (L1) objects. It describes an epoch-based design and per-partition state for determining when L0 objects can be removed without data loss or unnecessary storage use. ### Source excerpt How Redpanda Cloud Topics tracks the lifecycle of temporary L0 objects and determines when they're safe to delete, without risking data loss or runaway storage costs. Read more. ## Instrumenting AI: Multi-master replication and the split brain problem DevFeed: [Instrumenting AI: Multi-master replication and the split brain problem]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-05-17T00:00:00Z Content type: article Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [distributed-systems](), [Databases](), [AI Infrastructure](), [Raft](), [Availability](), [Network]() Tags: [ai](), [ai-infrastructure](), [conflict-resolution](), [consensus](), [database](), [distributed-systems](), [network](), [partitions](), [paxos](), [raft](), [split-brain]() ### AI overview The article explains how multi-master replication can produce split-brain behavior during network partitions. Both masters may accept conflicting writes, and reconciliation after the partition can discard valid data through last-write-wins rules. It presents Raft and Paxos quorum requirements as a way to prevent a second active brain. ### Source excerpt In multi-master replication every node accepts writes, so when the network partitions both masters stay active and accept conflicting writes into isolated silos. On heal, automated conflict resolution usually falls back to last-write-wins, which blindly discards valid data. Raft and Paxos prevent this by requiring an odd node count and a strict majority: an isolated leader cannot reach quorum, so it steps down instead of forming a second brain. ## 【分布式系统百科】etcd 深度解剖：从 Watch 机制到 MVCC 存储引擎 DevFeed: [【分布式系统百科】etcd 深度解剖：从 Watch 机制到 MVCC 存储引擎]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-04-13T00:00:00Z Content type: article Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Kubernetes](), [Raft]() Tags: [apiserver](), [boltdb](), [compaction](), [distributed](), [distributed-coordination](), [distributed-systems](), [etcd](), [kubernetes](), [lease](), [mvcc](), [raft](), [revision](), [streaming](), [watch]() ### AI overview This article explains etcd's persistent Watch mechanism, revision-based event replay, MVCC storage, and its relationship with Raft and WAL. It also describes how Kubernetes components use etcd Watch events to propagate Deployment and Pod changes, and discusses compaction limits and recovery through full resynchronization. ### Source excerpt 深入剖析 etcd 的核心机制：持久化 Watch 与 Revision 追溯、Lease 租约机制、基于 BoltDB 的 MVCC 存储引擎、与 Raft 共识的联动方式，以及在 Kubernetes 中的关键角色。涵盖性能调优策略、容量限制与规模化方案。 ## 【分布式系统百科】分布式 KV 存储对比：etcd、TiKV 与 FoundationDB DevFeed: [【分布式系统百科】分布式 KV 存储对比：etcd、TiKV 与 FoundationDB]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-04-13T00:00:00Z Content type: comparison Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [etcd](), [Raft](), [Kubernetes]() Tags: [bbolt](), [boltdb](), [compaction](), [coreos](), [distributed](), [distributed-systems](), [errcompacted](), [etcd](), [go](), [k8s](), [kubernetes](), [lease](), [mmap](), [mvcc](), [raft](), [readindex](), [revision](), [single-raft-group](), [ssd](), [v3](), [wal](), [watch]() ### AI overview This Chinese-language comparison examines etcd, TiKV, and FoundationDB as distributed key-value stores for metadata. It focuses on architecture, implementation, performance, and limitations, with detailed coverage of etcd's single Raft group, MVCC, Watch, Lease, bbolt storage engine, linearizable reads, compaction, and defragmentation. ### Source excerpt 一个典型的架构评审场景：团队需要一个分布式键值存储来承载新系统的元数据。候选方案三个----etcd、TiKV、FoundationDB。三者都提供强一致性保证，都经过大规模生产验证，但设计目标截然不同。选错了，轻则性能不达标，重则数据丢失后无法恢复。这篇文章从架构、实现、性能和局限四个维度，把三个系统拆开来看。 ## Under the hood: Redpanda Cloud Topics architecture DevFeed: [Under the hood: Redpanda Cloud Topics architecture]() Original publisher: [Read original article]() Author: Tyler Rockwood Published: 2026-03-30T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Streaming](), [Replication](), [Amazon S3](), [Raft](), [Kafka]() Tags: [engineering](), [kafka](), [object-storage](), [raft](), [replication](), [streaming]() ### AI overview This article explains Redpanda Cloud Topics, which store record payloads in object storage while retaining partition metadata in Raft logs. It describes batching writes for object storage, preserving transaction and idempotency logic through Raft metadata, and the feature's general availability in Redpanda Streaming 26.1. ### Source excerpt Cloud Topics represents a new replication mechanism in our Redpanda streaming engine that cuts costs by using object storage. Here's how it actually works. [Next page]()