Felix Berger holds a degree in computer engineering from ETH Zürich (dipl. Informatik-Ing. ETH) and has been building software for over 30 years, 19 of them at Google Switzerland as a software architect and tech lead, working on Calendar, Shopping and Maps. Since July 2026 he runs fbt Berger, an independent consultancy focused on distributed systems and high availability. He is the author of fbtberger-raft, a Raft library written from scratch in Java 17 and published under Apache 2.0.

LOCATION: Zürich
ROOM: PH Zürich, Lagerstrasse 2, 8090 Zürich, Building LAC, Room E071, Travel instructions
KEYWORDS: Architecture, Open Source, Tools

SPEAKER: Felix Berger   COMPANY: fbt Berger – Future Build Technology Berger

Anyone running Kubernetes, Kafka or Consul depends on a consensus algorithm every single day – most likely without ever having seen one. It is the reason a cluster can still agree on one shared truth when individual nodes fail or the network splits apart. And it is the reason two nodes must never both believe they are in charge.

Raft is considered one of the more approachable consensus algorithms. Leader election and log replication fit into a few pages of the paper. Between an understandable algorithm and a cluster you would trust with production data, however, lie a number of surprisingly hard details.

Felix Berger implemented Raft from scratch in Java 17, without a framework, and runs the resulting library in production. Many of the interesting problems only begin where the description of the algorithm meets the reality of distributed systems.

What happens when several nodes decide at the same moment that they should become leader? How do you prevent unstable elections? How do you make sure a read actually sees the current state of the cluster? And how do you change the membership of a running cluster without putting consistency at risk?

Using two reproducible bugs from his own operation, the talk shows concrete pitfalls of a production Raft implementation: a race condition that turns a single PreVote round into two elections, and a timing problem shortly after startup, where leader stickiness does not yet take hold and a freshly started follower wins the PreVote round.

Along the way we encounter PreVote and leader stickiness, ReadIndex and lease-based reads, joint consensus, and chunked copy-on-write snapshots. The failure cases are demonstrated live on a running cluster, including a leader failure during operation.

The library is open source under Apache 2.0, so the code can be read alongside the talk.

And at the end, perhaps the most important architectural question of all: when does an application genuinely need consensus, and when is a replicated database enough?

No prior knowledge of Raft required. Anyone who has ever run an application twice and wondered which instance is right already has everything they need.

LANGUAGE: Talk: en / Slides: en

Felix Berger holds a degree in computer engineering from ETH Zürich (dipl. Informatik-Ing. ETH) and has been building software for over 30 years, 19 of them at Google Switzerland as a software architect and tech lead, working on Calendar, Shopping and Maps. Since July 2026 he runs fbt Berger, an independent consultancy focused on distributed systems and high availability. He is the author of fbtberger-raft, a Raft library written from scratch in Java 17 and published under Apache 2.0.

---