Logische Brandschotts sind ein zentrales Architektur-Pattern zur Erhöhung der Resilienz komplexer IT-Systeme. Sie trennen Services, Komponenten oder Subsysteme bewusst voneinander, sodass Störungen nicht unkontrolliert auf andere Bereiche übergreifen. Das Pattern unterstützt Stabilität, Verfügbarkeit und Compliance und wird häufig in verteilten Systemen, Clo…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und bei Bedarf in die 360°-Bewertung zu wechseln.
Theoretisches Gebilde: erklärt einen Begriff, ein Prinzip oder ein Denkmodell.
Was du verstehen musst, um ein Themenfeld sinnvoll zu denken.
Ein logisches Brandschott isoliert konkurrierende Ressourcen oder Funktionsbereiche so, dass die Überlastung eines Bereichs die anderen möglichst nicht mitreißt.
Das Muster entstand aus dem Zuverlässigkeitsproblem gemeinsamer Ressourcen: Ein einzelner Fehler oder Laststoß kann sonst alle Aufrufer blockieren. Microsoft dokumentiert das Bulkhead Pattern als Resilienzmaßnahme; der Name greift das Schottprinzip aus dem Schiffbau auf und wurde auf Pools, Limits und getrennte Ausführung übertragen.
Stell dir ein Schiff mit wasserdichten Abteilen vor. Für Software sind das etwa getrennte Worker-Pools, Verbindungsbudgets oder Zeitkontingente; ein volllaufendes Abteil bleibt begrenzt, statt die ganze Anwendung zu fluten.
Ein Bereich erhält eigene Kapazitätsgrenzen, sodass er andere Bereiche nicht vollständig verbraucht.
Die Begrenzung beschreibt, wie weit sich ein Ausfall oder eine Überlastung ausbreiten darf.
Ein logisches Brandschott begrenzt Ausfallfolgen in verteilten und nebenläufigen Systemen. Es ergänzt Timeouts und Circuit Breaker, ersetzt sie aber nicht.
Wo dieser Baustein im Themenmodell verortet ist.
Keine Strukturpfade verfügbar.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.