• English
  • Deutsch
Analysis · Coaching · Custom Software · Zurich

From requirements
to resilient systems.

fbt Berger analyses your business requirements, empowers your team through coaching, and builds the custom software to match when you need it – on commercially usable open source, replicated via a self-built, tested Raft library.

30+ years19 of them at Google
Analysis & coachingas core services
Own Raft corefrom scratch, Apache-2.0
Arrange a call → View services

Understand requirements.
Empower teams.

Two core services form the focus – custom delivery comes on top whenever you need it.

Core service 01

Business Requirements Analysis

Before a single line of code: your business requirements captured cleanly, questioned critically and translated into a solution that will hold. From over 30 years of engineering – 19 of them on systems at global scale – I know which questions to ask early.

Structure, sharpen and prioritise business requirements
Assess technical feasibility, scaling and risks early
From requirement to a sound architecture decision
Core service 02

Coaching

I empower your team to ship faster and more safely on its own – with two areas of focus.

AI-assisted software development

Development at high velocity that still produces tested, documented and maintainable systems.

Large replicated systems

Building fault-tolerant, replicated architectures – in-house, for noticeably more data security and data sovereignty.

Delivery on request

Custom software development

If you would rather hand off delivery: custom software, built on the same foundation the reference projects run on.

Commercially usable open source Own Raft library · replication User management via Keycloak Apache-2.0 / MIT · legally clean

The foundation
behind the services.

Analysis and coaching only convince with real technical depth. Four building blocks every fbt Berger project stands on.

01

Distributed Systems & Consensus

Replication, quorum, fault tolerance and linearizable consistency. The machinery that keeps systems correct across node failures – a core competency, not a bought-in add-on.

02

Own Raft Library

A from-scratch implementation of the Raft algorithm in Java 17: leader election, log replication, joint consensus, snapshotting, linearizable reads. Apache-2.0 – so it can be used freely in your projects.

03

User Management with Keycloak

No reinventing authentication: I integrate Keycloak, the established open-source standard (OIDC / OAuth2, JWT) – multi-tenant and ready to use as a preconfigured setup.

04

Commercially Usable Foundation

Exclusively permissively licensed open-source components (Apache 2.0, MIT). Legally clean to use in your product – without copyleft traps.

Three projects.
One shared core.

The references are no coincidence: fbtberger-calendar and fbtberger-kwatro both use the same self-built Raft library for their replication. That proves the capability – and shows how fast it turns into working software.

CONSENSUS CORE fbtberger-raft L F F 3-node cluster · quorum REPLICATION REPLICATION fbtberger-calendar RFC-compliant calendar system · CalDAV · iTIP fbtberger-kwatro Distributed card game · gRPC · Svelte
14
Days · fbtberger-raft
to the first running version
Apache-2.0 · from scratch
9
Days · fbtberger-calendar
to the first running version
Distributed-systems demo platform
6
Modules · fbtberger-kwatro
proto · server · client · web · raft
Demo platform, built in days
These timeframes are what AI-assisted development makes possible: scope that is classically budgeted in months takes shape in days – with the same demands on tests, documentation and maintainability.
PDF Datasheet: the consensus core in detail →

The projects
in detail.

One reusable building block, two demo platforms that show what it makes possible.

Building block · Apache-2.0
fbtberger-raft
First version 14 days
Build time 14 days
Language Java 17
Status in active development
The consensus core – a complete Raft implementation from the ground up.

Implemented after Ongaro & Ousterhout, including the optimisations from the dissertation. This is the building block that gives client projects consistent replication across node failures.

Protocol Buffers gRPC / Netty / Hadoop RPC Berkeley DB JE Segmented WAL · CRC32 Prometheus / JMX TLS · mTLS
Leader election with PreVote & leader stickiness against partition disruptions
Cluster reconfiguration via single-step and joint consensus
Log compaction with chunked, copy-on-write snapshots
Linearizable reads via ReadIndex and lease-based
Chaos tests, JMH benchmarks and multi-transport integration tests
PDF Datasheet fbtberger-raft · 1 page →
Demo platform
fbtberger-calendar
First version 9 days
Build time 9 days
Stack Spring Boot 3.3
Purpose Capability proof
An RFC-compliant calendar system that shows the distributed architecture under load.

A pure demo platform: built to prove skills in distributed systems and AI-assisted software development. It combines standards compliance with serious scaling decisions – replicated via fbtberger-raft, secured with Keycloak.

Java 17 Spring Boot 3.3 PostgreSQL Keycloak · OIDC RFC 5545 / 5546 / 4791 fbtberger-raft
iTIP fanout / fanback with RFC-5546 conflict resolution
O(1) memory usage for events with 100,000+ attendees
Federation of external principals via iMIP (RFC 6047 / 6638)
Eventual consistency with four coordinated mechanisms
Docker cluster with mTLS and quorum-aware health checks
Demo platform
fbtberger-kwatro
Period June 2026
Structure 6 modules
Stack gRPC · Svelte
Purpose End-to-end demo
A distributed multiplayer card game as a compact architecture demonstration.

A pure distributed-systems demo platform: taken end to end from protocol to web frontend. It shows how a typed gRPC interface, replicated state and a reactive UI cleanly work together.

Java 17 Spring Boot 3.3 gRPC 1.64 Protocol Buffers Svelte · Vite fbtberger-raft
Multi-module structure: proto, server, client, web and Raft integration
Typed game protocol entirely over Protocol Buffers
Replicated game state based on the own consensus core
Reactive Svelte frontend with lobby, board and scoreboard

From over 30 years of engineering
to self-employment.

It starts in 1992 with a computer science degree from ETH Zurich – in practice earlier, with software work alongside the studies. Fifteen years follow across production control systems, intralogistics, engineering management and architecture consulting.

From August 2007 to February 2026 I worked at Google Switzerland GmbH on software at large scale – systems where availability, consistency and clean engineering are not optional but a given.

Since 2026 I have brought that experience together in fbt Berger – Future Build Technology Berger. As a sole proprietorship in Zurich, I build custom distributed systems for European SMEs: close to the client, without friction, on a foundation proven over years.

The phoenix in the logo is deliberate: proven engineering, set up anew.
1986–1992

ETH Zurich

Computer science degree (dipl. Informatik-Ing. ETH) – accompanied throughout by part-time software engineering at ABC Systems AG.

1989–1997

Production control and intralogistics

Application development at Mettler-Toledo, then project manager at VOLAG AG: a radio-linked warehouse management system, rolled out at more than six retail customers.

1997–2007

Management, consulting, architecture

Head of development and managing director roles at GLANCE and MEDICA, then senior consultant at sd&m and software engineer at PDF Tools AG.

2007–2026

Google Switzerland

19 years of engineering at global scale – incl. Google Calendar, Shopping and Maps.

2026

Founding of fbt Berger

Sole proprietorship in Zurich for custom distributed software – consulting, coaching, delivery.

2026 →

Core & references

Own Raft library plus two demo platforms as documented proof of capability.

Selected roles at Google
Google Calendar

Contributed to Google Calendar

Calendar and scheduling logic at global scale – exactly the domain behind the calendar reference.

→ Calendar domain depth
Google Shopping

Designed an AI-based policy-enforcement pipeline

Automated detection of policy violations using machine learning – designed for the Shopping catalogue.

→ AI-driven pipelines
Google Maps

Helped introduce incident display

Helped shape the display of incidents in Google Maps – real-time data, visible to millions of users.

→ Real-time & distributed systems

How I work.
Stated up front.

The terms of engagement belong at the start of a conversation, not at the end of one. Here is the shape of a mandate with fbt Berger – so you can tell within a minute whether it fits.

Engagement

Mandate, not employment

I work on a mandate basis as an independent Swiss company – no employment relationship and no staff leasing. Contract, liability and social insurance sit with fbt Berger.

Capacity

Part-time by design, around 60%

Deliberately reserved capacity: it keeps room for parallel mandates and for the continued development of the technical core my clients build on.

Location

Remote-first, one day on site per week

Switzerland and the wider DACH region. One regular on-site day a week keeps a team connected; the rest is more productive remote.

Availability

Immediate

No notice period to serve – as a sole proprietor I can start as soon as the scope is clear.

Contact

You talk to the person who builds it

No account management, no handover to a delivery team you have not met. The person answering your first email is the person writing the code – which is also why I take on a small number of mandates rather than many.

Not a fit? Then it is better established now than after three weeks. If your project needs full-time presence, a permanent hire or on-site work every day, I am happy to say so early.

Where an outage
stops the floor.

One focus area: the control layers of intralogistics – warehouse management, warehouse execution and material flow control. Availability there is not a quality attribute. It is the precondition for anything moving at all.

The layer

WES and material flow control

Between warehouse management and machine control sits the layer that knows which order is where right now. That state is short-lived, business-critical – and cannot be reconstructed from the WMS.

The risk

The state lives on one node

Many of these systems grew over decades and hold their runtime state on a single instance. When it fails, what is missing is not a service but the knowledge of what the floor is currently doing.

The answer

Replicated state, not a failover script

Consensus replication across several nodes: the state exists more than once, a node failure costs seconds instead of hours, and nobody has to maintain a restart order by hand.

The background

From hands-on project work

Project manager at VOLAG AG, Schlieren: a radio-linked warehouse management system for retail distribution centres, rolled out at more than six customers. Largest site: over 10,000 storage locations, around 5,000 picking orders a day, more than 50 radio terminals in real-time operation.

Safety-critical

Experience from environments where mistakes are expensive

As a senior consultant at sd&m: requirements engineering with DOORS for a fire alarm control panel, and an architecture audit in a nuclear power plant context. Traceability there is not a documentation duty but part of the construction – a mindset machine control benefits from too.

The Raft library the fbt Berger solutions build on was written for exactly this case: state that has to survive a node failure without anyone opening a runbook at night.

The same pattern,
other industries.

Intralogistics is the focus, not the limit. The pattern repeats wherever a system holds state that is short-lived, business-critical and impossible to reconstruct – and where nobody is on site to restore it after a failure.

Charging infrastructure

One power budget, handed out twice

A depot with forty charge points has a fixed grid connection. The controller knows which point currently holds how much power. If it fails and two instances start from stale state, the same budget is allocated twice and the main breaker trips. That budget exists nowhere but in the controller.

Laboratory

A sample without a patient is waste

Between collection and analyser, the sample-to-patient mapping lives in the transport control layer. Lose it and the sample is not wrong – it is worthless, and the patient has to come back. The LIS knows the order, but not which carousel the tube is sitting in right now.

Regulated production

Two batch records are worse than none

Who released which batch, and when. A split brain produces two records that both look plausible. In an audit that is worse than an outage: downtime can be explained, two contradictory truths cannot.

Shared resources

Who holds the crane right now

Crane, AGV, test bench, dock slot: the pure coordination problem without any domain dressing. Usually solved with a home-grown lock table – the one that fails precisely when the network between shop floor and server room blinks.

Where it does not belong

Safety functions stay where they are

Emergency stop, guard door monitoring, two-hand control: that is safety PLC territory and it stays there. Consensus replicates operating state, not safety logic. Anyone claiming otherwise is selling you a risk, not an architecture.

Whether a case genuinely calls for a replicated cluster is decided during requirements analysis – sometimes the honest answer is a replicated database and better monitoring.

Talks
and knowledge transfer.

Two appearances at the Java User Group Switzerland in November 2026 – on what actually lies between the Raft paper and a cluster in production. Including two bugs from my own implementation, reproduced live on a five-node Raspberry Pi cluster.

JUGS Bern · Talk
Raft von Hand
Date 10 November 2026
Time 18:00
Venue vatter Business Center, Bern
Language German
Was zwischen dem Paper und einem produktiven Cluster liegt.

The paper describes the algorithm. It does not describe what happens when a freshly booted follower joins a running cluster, or when a single PreVote round produces two elections. Both are bugs from fbtberger-raft – triggered live on the demo cluster rather than shown on a slide.

Leader election · PreVote Log replication Joint consensus Live demo · 5 nodes
Where the paper stops and the implementation decisions start
Two real race conditions, from symptom to root cause
What only surfaces with real hardware, real timeouts, real partitions
Announcement and registration at JUGS Bern→
JUGS Zürich · Talk
Raft by Hand
Date 26 November 2026
Time 18:15
Venue PH Zürich, Lagerstrasse 2
Language English
What lies between the paper and a production cluster.

The English edition of the Bern talk. Same demo cluster, same two bugs, same question: which parts of a consensus implementation only reveal themselves once the system leaves the test suite and has to survive a pulled power cable.

Snapshots · log compaction Linearizable reads Chaos testing Live demo · 5 nodes
Failover on real hardware, not in a simulator
Cluster reconfiguration during operation
What operating a replicated system actually costs
Announcement and registration at JUGS Zürich→
Both talks are listed at jug.ch. In-house editions and workshops on distributed systems and AI-assisted software development are available on request.

Let's build your system.

Whether consulting, coaching or full delivery – tell me what you have in mind. The reply comes from the person who also does the building.

Write an email →
fbt Berger
Future Build Technology Berger
Riedhofstrasse 98
8049 Zürich · Switzerland
© 2026 fbt Berger · Future Build Technology Berger · Riedhofstrasse 98, 8049 Zürich