Wenn ein Fehler alles trifft – Warum Building-Blocks die Grundlage resilienter Systeme sind

09.12.2025 · architecture, infrastructure, resilience, cloud, strategy, core2code

Wenn ein globaler Fehler alles trifft – Warum wir Systeme in echte Building-Blocks zerlegen müssen

Der Cloudflare-Ausfall vom 5. Dezember hat erneut gezeigt, wie fragil selbst hochmoderne Internet-Infrastruktur sein kann. Ein einzelner Konfigurationsfehler führte dazu, dass rund ein Viertel des weltweiten HTTP-Traffics zeitweise nicht erreichbar war. 500-Fehler in Serie, ausgefallene Dashboards, fehlerhafte Firewall-Logik – und binnen Minuten standen große Teile des Netzes still.

Viel wurde über den konkreten Bug diskutiert. Aber aus architektonischer Sicht ist der eigentliche Punkt ein anderer: Nicht der Fehler war das Problem, sondern die Größe der Einheit, in der er wirksam wurde. Der Ausfall war so massiv, weil er auf einer Ebene stattfand, die global wirkte – ein „Building-Block“, der im Grunde keiner war, sondern eine zentrale gemeinsame Schicht, die alles verband.

Damit stellt sich eine grundsätzliche Frage: Wie müssen moderne Systeme gebaut sein, damit ein einzelner Fehler nicht das Ganze trifft?

Die Antwort führt direkt zu einer Architektur, die in vielen Unternehmen noch nicht selbstverständlich ist – der konsequenten Zerlegung in unabhängige Building-Blocks mit klaren Grenzen, minimalen Abhängigkeiten und isolierten Betriebsbereichen.

Building-Blocks sind keine Metapher – sie sind eine technische Notwendigkeit

In vielen Architekturdiskussionen werden „Module“, „Services“ oder „Domänen“ als lose Einheiten verstanden, die sich bei Bedarf überschneiden dürfen. Doch aus Resilienzsicht genügt das nicht. Ein Building-Block ist nur dann ein Block, wenn er eine echte Grenze besitzt:

• eigene Laufzeitumgebung
• eigenes Datenmodell
• eigene Skalierung
• eigene Ressourcenzuteilung
• eigene Management-Pipeline
• eigene Fehlerdomäne

Erst wenn all das zusammenkommt, entsteht Isolation: Ein Fehler bleibt innerhalb seines Blocks.

Ein Beispiel aus der Praxis: Viele Provider – Cloudflare eingeschlossen – betreiben eine Proxy-Schicht, die für sämtliche eingehenden Requests verantwortlich ist. Obwohl die Dienste dahinter verteilt und redundant aufgebaut sind, bleibt diese Schicht ein globaler, monolithischer Bestandteil. Ein Konfigurationsfehler in dieser Schicht entfaltet dann sofort eine enorme Wirkung – weil sie als einzelner Block konzipiert ist, obwohl sie es nicht sein dürfte.

Der Kernpunkt lautet also: Stabilität entsteht nicht durch Redundanz, sondern durch richtige Schnitte.

Warum Überschneidungen in Building-Blocks gefährlich sind

Viele Architekturen scheitern nicht an ihren Komponenten, sondern an ihren stillen Überschneidungen. Das kann ein globales Config-Set sein, ein gemeinsamer State, ein geteiltes CI/CD-System oder ein zentrales Observability-Backend.

Solange Building-Blocks irgendwo gemeinsam betrieben oder verwaltet werden, bleiben sie gekoppelt – manchmal unbemerkt, bis ein Fehler auf genau dieser Ebene zuschlägt.

Typische Anti-Patterns:

• Ein gemeinsames Firewall-Regelwerk, das bei Änderungen alle Tenants betrifft
• Zentrale Management-Systeme, über die Deployments in allen Bereichen gleichzeitig erfolgen
• Verteilte Systeme, die am Ende doch eine einzige globale Rate-Limit- oder Routing-Quelle nutzen
• Teams, die fachlich getrennte Services betreiben, aber denselben Operabilitäts-Pfad teilen

Solche Überschneidungen erzeugen „versteckte Kopplungspunkte“. Im Normalbetrieb merkt man sie nicht – aber im Fehlerfall erzeugen sie einen überproportional großen Blast Radius.

Aus diesem Grund ist die Forderung, Building-Blocks auch organisatorisch und operativ vollständig zu trennen, nicht überzogen, sondern logisch konsequent. Ein Block, der nicht selbstständig betrieben werden kann, ist kein Block – er ist ein Pseudomodul innerhalb eines größeren Monolithen.

Fault Domains, Cells und Bulkheads – die theoretische Basis

Fault Domains

Eine Fault Domain ist ein Bereich, in dem ein Fehler sich ausbreiten darf. Ziel ist, diese Bereiche so zu schneiden, dass Fehler nur einen minimalen Teil des Systems betreffen. Building-Blocks entsprechen 1:1 eigenständigen Fault Domains.

Bulkhead Pattern

Aus der Schifffahrt übernommen: Das Schiff wird in isolierte Sektionen unterteilt, damit ein Leck nicht das gesamte Schiff flutet. Übertragen bedeutet das:

• Jede Einheit hat eigene Ressourcen.
• Der Ausfall einer Einheit führt nicht zum Ausfall anderer Einheiten.
• Es gibt keine gemeinsamen Engpässe.

Cell-based Architecture

Hyperscaler wie AWS oder Medienplattformen wie Netflix nutzen „Cells“: Jede Cell ist ein vollständiger, unabhängiger Stack – Compute, Netzwerk, Daten, Routing, Observability. Neue Nutzer oder Tenants werden auf mehrere Cells verteilt. Fällt eine Cell aus, ist nur ein Bruchteil der User betroffen.

Diese Konzepte sind nicht theoretisch – sie sind gelebte Realität in Systemen, die extrem hohe Anforderungen an Verfügbarkeit haben.

Warum der vollständige Schnitt (inkl. Management) entscheidend ist

Building-Blocks dürfen keine Überschneidungen haben – auch nicht im Management und bei abhängigen Services.

Das bedeutet:

• eigene Pipelines
• eigene Deploy-Zeitpunkte
• eigene Routing-Konfiguration
• eigene Limits
• eigene Observability-Scopes
• idealerweise sogar eigene IAM-Bereiche

Gerade der Cloudflare-Ausfall zeigt, warum das wichtig ist. Der Fehler entstand nicht im Datenpfad selbst, sondern bei der Konfigurationsverteilung. Er wurde global ausgerollt – was bedeutet: Die Management-Ebene war eine einzige Fault Domain.

Wenn der operative Layer eines globalen Systems als monolithischer Block ausgelegt ist, hilft die gesamte Verteilung der darunterliegenden Services wenig. Verteilte Systeme, die zentral gemanagt werden, sind keine verteilten Systeme. Sie sind ein globaler Monolith – nur auf mehreren Maschinen.

Wie realistisch ist eine Architektur ohne Überschneidungen?

Technisch ist sie realistisch. Wirtschaftlich muss man differenzieren.

• Kritische Bereiche (Identity, Payment, Core-Workflow, Routing) sollten vollständig eigene Building-Blocks erhalten – inklusive Management. Alles andere erzeugt strategische Risiken.

• Unkritische Bereiche (Reporting, Content, Marketing-Frontends) können sich Management-Tools teilen, wenn klar definiert ist, welche Konsequenzen ein Ausfall hätte.

Die Kunst liegt also darin, nicht alles maximal zu isolieren, sondern die richtigen Building-Blocks mit der richtigen Tiefe zu schneiden.

Architekturelle Leitgedanken, die wir aus dem Vorfall ableiten können

1. Zentralisierung ist das größte Risiko moderner Plattformen. Nicht der Ausfall einzelner Komponenten, sondern der Ausfall zentraler Management-Pfade verursacht die großen Störungen.

2. Die Größe einer Fault Domain bestimmt den Impact eines Fehlers. Kleinere, klar geschnittene Building-Blocks erzeugen kleinere Ausfälle.

3. Unabhängigkeit ist mehrdimensional. Technische Trennung ohne organisatorische Trennung ist wertlos. Fachliche Trennung ohne operative Trennung ebenso.

4. „Shared-Nothing“ ist kein Dogma, sondern Resilienz-Prinzip. Das Ziel ist nicht Vervielfachung, sondern Sauberkeit: Doppelung von Wichtigem ist billiger als globale Ausfälle.

5. Globale Konfigurationen sind gefährlicher als globaler Code. Konfigurationsfehler sind schneller, unauffälliger und oft direkter wirksam.

Fazit

Der Cloudflare-Vorfall vom 5. Dezember ist weniger ein technischer Unfall, sondern ein architekturischer Hinweis. Nicht der Fehler selbst war außergewöhnlich – Fehler passieren jeden Tag –, sondern wo der Fehler stattfand: in einem globalen, unzureichend geschnittenen Block.

Architekturen, die auf echte Building-Blocks setzen, begrenzen den Schaden solcher Fehler automatisch. Das Internet ist zu groß für globale Monolithen – selbst wenn sie hochperformant sind. Die Zukunft gehört Systemen, die aus vielen kleinen, unabhängigen Zellen bestehen, die sich ohne gegenseitige Abhängigkeiten betreiben lassen.

Solche Architekturen sind kein Luxus, sondern die Grundlage dafür, dass ein einzelner Fehler nicht wieder ein Viertel des Netzes stilllegt.