Felix Berger ist dipl. Informatik-Ing. ETH und seit über 30 Jahren in der Softwareentwicklung tätig, davon 19 Jahre bei Google Schweiz als Softwarearchitekt und Tech Lead an Calendar, Shopping und Maps.

Seit Juli 2026 ist er mit der Einzelfirma fbt Berger in Zürich selbständig, mit Schwerpunkt auf verteilten Systemen und Hochverfügbarkeit. Er ist Autor von fbtberger-raft, einer von Grund auf in Java 17 entwickelten und unter Apache 2.0 veröffentlichten Raft-Bibliothek, die er produktiv betreibt.

LOCATION: Bern
ROOM: vatter Business Center, Bärenplatz 2, 3011 Bern, Raum Frutiger, Anreiseinformationen
KEYWORDS: Architecture, Open Source, Tools

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

Wer Kubernetes, Kafka oder Consul betreibt, verlässt sich täglich auf einen Konsensalgorithmus - meist ohne je einen gesehen zu haben. Er ist der Grund, weshalb sich ein Cluster auch dann noch auf eine gemeinsame Wahrheit einigen kann, wenn einzelne Knoten ausfallen oder das Netzwerk auseinanderbricht. Und er ist der Grund, weshalb nicht zwei Knoten gleichzeitig glauben dürfen, sie hätten das Sagen.

Raft gilt als einer der verständlicheren Konsensalgorithmen. Leader Election und Log Replication lassen sich im Paper auf wenigen Seiten erklären. Doch zwischen einem verständlichen Algorithmus und einem Cluster, dem man Produktivdaten anvertraut, liegen einige überraschend schwierige Details.

Felix Berger hat Raft in Java 17 von Grund auf und ohne Framework implementiert und setzt die daraus entstandene Bibliothek produktiv ein. Viele der interessanten Probleme beginnen erst dort, wo die Beschreibung des Algorithmus auf die Realität verteilter Systeme trifft.

Was passiert, wenn mehrere Nodes gleichzeitig entscheiden, sie müssten Leader werden? Wie verhindert man instabile Elections? Wie stellt man sicher, dass ein Read tatsächlich den aktuellen Stand des Clusters sieht? Und wie verändert man die Mitglieder eines laufenden Clusters, ohne dabei die Konsistenz zu gefährden?

Anhand von zwei reproduzierbaren Fehlern aus dem eigenen Betrieb zeigt der Vortrag konkrete Fallstricke einer produktiven Raft-Implementierung: eine Race Condition, die aus einer einzelnen PreVote-Runde zwei Wahlen macht, und ein Timing-Problem kurz nach dem Start, bei dem Leader Stickiness noch nicht greift und ein frisch gestarteter Follower die PreVote-Runde gewinnt.

Dabei begegnen uns unter anderem PreVote und Leader Stickiness, ReadIndex und Lease-basierte Reads, Joint Consensus sowie Chunked Copy-on-Write-Snapshots. Die Fehlerfälle werden live auf einem laufenden Cluster demonstriert - inklusive Leader-Ausfall im Betrieb.

Die Bibliothek ist unter Apache 2.0 quelloffen, sodass der Code während des Vortrags direkt mitgelesen werden kann.

Und am Ende steht vielleicht die wichtigste Architekturfrage überhaupt: Wann braucht eine Anwendung tatsächlich Konsens, und wann genügt eine replizierte Datenbank?

Raft-Kenntnisse sind nicht nötig. Wer schon einmal eine Anwendung doppelt betrieben und sich gefragt hat, welche Instanz nun recht hat, bringt alles mit, was es braucht.

LANGUAGE: Talk: de / Slides: en

Felix Berger ist dipl. Informatik-Ing. ETH und seit über 30 Jahren in der Softwareentwicklung tätig, davon 19 Jahre bei Google Schweiz als Softwarearchitekt und Tech Lead an Calendar, Shopping und Maps.

Seit Juli 2026 ist er mit der Einzelfirma fbt Berger in Zürich selbständig, mit Schwerpunkt auf verteilten Systemen und Hochverfügbarkeit. Er ist Autor von fbtberger-raft, einer von Grund auf in Java 17 entwickelten und unter Apache 2.0 veröffentlichten Raft-Bibliothek, die er produktiv betreibt.

---