Read in English · Leer en español · Lire en français

Glossar der Softwarearchitektur

Kurze Definitionen der 914 Begriffe aus den veröffentlichten Kapiteln, jeweils verlinkt mit dem Kapitel, das sie erklärt.

0–9

4+1-Sichtenmodell: Der Ansatz von Philippe Kruchten aus dem Jahr 1995, der ein System durch eine logische Sicht, eine Prozesssicht, eine Entwicklungssicht und eine physische Sicht beschreibt, verbunden durch eine kleine Zahl von Szenarien. Kapitel 4

A

Abhängigkeit: Jede Software, die Ihr Code zum Funktionieren braucht, etwa eine Bibliothek, ein Framework oder ein anderer Service. Wenn sie sich ändert oder ausfällt, kann auch Ihr Code ausfallen. Kapitel 0
Abhängigkeitsregel (Dependency Rule): Die Regel von Robert C. Martin für Clean Architecture: Quellcode-Abhängigkeiten zeigen nur nach innen, sodass innere Ringe nie etwas benennen, das in äußeren Ringen deklariert ist. Kapitel 5
Abhängigkeitsumkehr: Ein High-Level-Modul und ein Low-Level-Modul hängen beide von einer Abstraktion ab, die meist der High-Level-Seite gehört, sodass die Quellcode-Abhängigkeit entgegen dem Kontrollfluss zeigt. Kapitel 3
Abhängigkeitszyklus: Eine Schleife, in der Module direkt oder indirekt voneinander abhängen, sodass keines für sich allein verstanden, getestet oder ausgeliefert werden kann. Kapitel 1
Abstraktheit (A): Martins Metrik: die Zahl der abstrakten Klassen und Schnittstellen einer Komponente geteilt durch die Gesamtzahl ihrer Klassen, von 0 (vollständig konkret) bis 1 (vollständig abstrakt). Kapitel 3
Abstraktion: Eine vereinfachte Sicht auf etwas, die für einen bestimmten Zweck das Wesentliche behält und den Rest weglässt, etwa eine „Datei“, die Festplatten, Sektoren und Caching verbirgt. Kapitel 3
Abwägung (Trade-off): Eine Wahl, bei der man für einen Vorteil Kosten in Kauf nimmt oder auf einen anderen Vorteil verzichtet, etwa schnellere Auslieferung um den Preis höherer Betriebskosten. Kapitel 1
Abwärtskompatibilität: Eine Schemaänderung ist abwärtskompatibel, wenn Code, der das neue Schema verwendet, weiterhin Daten lesen kann, die mit dem alten geschrieben wurden. Kapitel 7
Abwärtskompatible Änderung: Eine Änderung an einer Schnittstelle oder einem Schema, die bestehende Consumer ohne Anpassung überstehen, etwa das Hinzufügen eines optionalen Felds. Das Entfernen oder Umbenennen eines Felds ist ein Breaking Change. Kapitel 6
Access Token: Ein kurzlebiger Berechtigungsnachweis, der nach der Anmeldung eines Benutzers oder einer Anwendung ausgestellt und mit jeder API-Anfrage mitgesendet wird, um zu belegen, was der Aufrufer tun darf. Kapitel 0
ACID: Atomarität, Konsistenz, Isolation, Dauerhaftigkeit: die Garantien einer Datenbanktransaktion, damit die Daten trotz Abstürzen und gleichzeitiger Benutzer korrekt bleiben. Kapitel 0
ACM Code of Ethics: Der Code of Ethics and Professional Conduct der Association for Computing Machinery, 2018 überarbeitet; zu seinen Grundsätzen gehören ein Beitrag zur Gesellschaft, die Vermeidung von Schaden, Ehrlichkeit, Fairness, Privatsphäre und Vertraulichkeit. Kapitel 11
Active-Active (Multi-Site): Eine Anordnung, bei der zwei oder mehr Regionen gleichzeitig Live-Traffic bedienen, sodass der Verlust einer Region kein Failover erfordert, sondern nur eine Umverteilung des Traffics. Kapitel 10
Acyclic Dependencies Principle: Das Prinzip von Robert C. Martin, nach dem der Abhängigkeitsgraph zwischen Komponenten keine Zyklen enthalten darf. Kapitel 3
Adapter: Code, der zwischen einem Port und einer bestimmten Technologie übersetzt, etwa ein HTTP-Controller, ein SQL-Repository oder das SDK eines Zahlungsanbieters. Ein Port kann viele Adapter haben. Kapitel 5
Advice Process: Eine dezentrale Art der Entscheidungsfindung, bei der jede Person entscheiden darf, sofern sie vorher den Rat der Betroffenen und der zuständigen Fachleute einholt. Kapitel 4
Afferente Kopplung (Ca): Die Zahl der Elemente außerhalb einer Komponente, die von ihr abhängen: ihre eingehenden Abhängigkeiten. Eine hohe Ca bedeutet, dass viele andere betroffen sind, wenn sie sich ändert. Kapitel 3
Agent: Ein System, in dem ein Modell wiederholt Aktionen wie Tool-Aufrufe wählt, die Ergebnisse beobachtet und über den nächsten Schritt entscheidet, bis ein Ziel erreicht oder ein Limit erreicht ist. Kapitel 12
Aggregat: Eine Gruppe von Domänenobjekten, die als eine Einheit über eine einzige Wurzelentität geändert wird; diese setzt die Regeln durch, die für die Gruppe immer gelten müssen. Kapitel 5
Agile Softwareentwicklung: Eine Familie von Ansätzen der Softwareentwicklung, beschrieben im Agilen Manifest von 2001, die in kurzen Zyklen funktionierende Software liefern und Pläne anhand von Feedback anpassen. Kapitel 0
AI-Gateway: Eine Komponente zwischen Anwendungen und Modellanbietern, die Zugangsdaten, Routing, Fallbacks, Kontingente, Logging und Richtlinienprüfungen für Modellaufrufe zentral bündelt. Kapitel 12
Aktivitätsdiagramm: Ein UML-Diagramm, das einen Ablauf als Aktionen, Entscheidungen, parallele Verzweigungen und Zusammenführungen zeigt, oft in Schwimmbahnen (Swimlanes) unterteilt, die zeigen, wer was tut. Kapitel 4
Akzidentelle Komplexität: Komplexität, die durch die Art entsteht, wie eine Lösung gebaut ist (Werkzeuge, Struktur, Notlösungen), und nicht durch das Problem selbst. Sie lässt sich grundsätzlich beseitigen. Kapitel 3
Algorithmischer Bias: Systematisch schlechtere Ergebnisse eines automatisierten Systems für bestimmte Personengruppen, verursacht durch Daten, Design oder den Einsatzkontext. Kapitel 12
Algorithmus: Ein präzises, schrittweises Verfahren zur Lösung eines Problems, etwa zum Sortieren einer Liste oder zum Finden des kürzesten Wegs, das immer zu einem Ende kommt. Kapitel 0
Allgemeines Szenario: Eine systemunabhängige Vorlage, die die typischen Quellen, Stimuli, Umgebungen, Reaktionen und Maße für ein Qualitätsmerkmal auflistet. Kapitel 2
Altsystem (Legacy-System): Ein bestehendes System, das noch Nutzen stiftet, aber schwer, riskant oder teuer zu ändern geworden ist, oft wegen seines Alters, fehlender Tests, knapper Fachkenntnisse oder nicht mehr unterstützter Technologie. Kapitel 11
Amdahlsches Gesetz: Eine Formel (Gene Amdahl, 1967), die zeigt, dass der Geschwindigkeitsgewinn durch zusätzliche Prozessoren durch den Teil der Arbeit begrenzt ist, der seriell laufen muss. Kapitel 2
Amortisationszeit: Wie lange es dauert, bis der kumulierte Nutzen die Kosten einer Investition zurückgezahlt hat; die dynamische (abgezinste) Amortisationszeit tut dasselbe mit abgezinsten Zahlungsströmen. Kapitel 11
Änderbarkeit: Wie kostengünstig und sicher sich ein System ändern lässt: die Kosten, der Aufwand und das Risiko einer Änderung und wie weit sie über die Stelle hinaus wirkt, an der sie vorgenommen wird. Kapitel 2
Änderungskosten: Der Aufwand, das Geld, die Zeit und das Risiko, die nötig sind, um eine Entscheidung zu ändern, nachdem bereits darauf aufgebaut wurde. Kapitel 1
Anforderung: Eine Aussage darüber, was ein System tun muss oder welche Qualität es haben muss, abgestimmt mit den Menschen, die es brauchen. Kapitel 0
Anforderungserhebung: Das aktive Herausarbeiten von Anforderungen aus Stakeholdern, Dokumenten, Vorschriften und bestehenden Systemen, statt darauf zu warten, dass sie genannt werden. Kapitel 2
Angriffsbaum: Ein Baum, dessen Wurzel das Ziel eines Angreifers ist und dessen Kinder die alternativen (ODER) oder kombinierten (UND) Wege dorthin sind, 1999 von Bruce Schneier bekannt gemacht. Kapitel 8
Angriffsfläche: Die Gesamtheit der Stellen, an denen ein Angreifer versuchen kann, Daten in ein System einzubringen, Daten daraus abzuziehen oder anderweitig mit ihm zu interagieren: Endpoints, Ports, Dateien, Queues, Admin-Werkzeuge sowie die Menschen und der Code, denen es vertraut. Kapitel 8
Anliegen: Ein Interesse, das ein Stakeholder an einem System hat, etwa seine Kosten, Performance, Sicherheit, Änderbarkeit oder die Einhaltung rechtlicher Vorgaben. Kapitel 1
Anomalie (Phänomen): Ein falsches Ergebnis, weil sich nebenläufige Transaktionen gegenseitig stören, etwa ein Dirty Read, ein Lost Update oder ein Write Skew; Isolationsebenen werden dadurch definiert, welche Anomalien sie verhindern. Kapitel 7
Anonymisierung: Die Verarbeitung von Daten in einer Weise, dass sie sich mit keinem Mittel, das vernünftigerweise eingesetzt würde, mehr auf eine identifizierbare Person beziehen; wirklich anonyme Daten fallen nicht unter die DSGVO. Kapitel 8
Anti-Corruption Layer: Eine Übersetzungsschicht aus dem Domain-Driven Design, die zwischen dem Modell eines anderen Systems und dem eigenen übersetzt, damit dessen Konzepte und Eigenheiten nicht in den eigenen Code durchsickern. Kapitel 11
Anti-Pattern: Eine häufig verwendete Lösung, die vernünftig aussieht, aber zuverlässig mehr Probleme verursacht, als sie löst. Kapitel 5
Anticorruption Layer: Eine Übersetzungsschicht, die ein nachgelagerter Kontext baut, damit das Modell eines anderen Kontexts oder Systems nicht in sein eigenes durchsickern kann. Kapitel 5
Antwortmaß (Response Measure): Die Zahl, die ein Szenario testbar macht, etwa „99 % innerhalb von 800 ms“, „Service innerhalb von 2 Minuten wiederhergestellt“ oder „Änderung in 3 Personentagen abgeschlossen“. Kapitel 2
Antwortzeit: Die Gesamtzeit zwischen dem Senden einer Anfrage durch einen Client und dem Empfang der Antwort: die Bedienzeit plus etwaige Wartezeiten in Warteschlangen plus Netzwerkverzögerungen. Kapitel 2
Anycast: Die Bekanntgabe derselben IP-Adresse von vielen Standorten aus, sodass das Routing des Internets die Pakete jedes Benutzers an den nächstgelegenen Standort liefert, der sie bekannt gibt. Kapitel 9
API (Programmierschnittstelle): Eine festgelegte Menge von Operationen, Eingaben und Ausgaben, über die eine Software eine andere nutzt, ohne wissen zu müssen, wie diese intern funktioniert. Kapitel 0
API-Gateway: Ein einziger Einstiegspunkt vor den Services, der Querschnittsanliegen wie TLS, Authentifizierung, Rate Limiting und Routing übernimmt. Kapitel 6
API-Schlüssel: Eine lange geheime Zeichenkette, die die aufrufende Anwendung gegenüber einer API identifiziert. Wer den Schlüssel besitzt, kann als diese Anwendung auftreten, daher muss er geheim gehalten werden. Kapitel 0
API-Versionierung: Die Veröffentlichung von Änderungen an einer API unter einer neuen Versionskennung wie /v2/, während die alte Version eine Zeit lang weiter funktioniert, damit Clients in ihrem eigenen Tempo umsteigen können. Kapitel 0
API-Vertrag: Das dokumentierte Versprechen einer API: welche Anfragen sie annimmt, was jede zurückgibt, welche Fehler auftreten können und was sich nicht ohne Vorankündigung ändert. Kapitel 0
Approximative Nächste-Nachbarn-Suche: Das schnelle Finden der Vektoren, die einem Anfragevektor am nächsten liegen, mithilfe eines Index, der ein wenig Recall gegen große Geschwindigkeitsgewinne eintauscht. Kapitel 12
arc42: Eine kostenlose Vorlage mit zwölf Abschnitten zur Dokumentation und Kommunikation von Softwarearchitektur, entwickelt von Gernot Starke und Peter Hruschka. Kapitel 4
Architect Elevator: Das Bild von Gregor Hohpe für den Architekten oder die Architektin als jemand, der zwischen dem Penthouse einer Organisation (Strategie und Führungsebene) und ihrem Maschinenraum (Code und Infrastruktur) hin- und herfährt und beide verbindet. Kapitel 11
Architectural Runway: Im Scaled Agile Framework der vorhandene Code, die Komponenten und die Infrastruktur, die nötig sind, um kurzfristig geplante Features ohne übermäßiges Umgestalten und Verzögerung umzusetzen. Kapitel 1
Architecture Advisory Forum: Ein regelmäßiges, offenes Treffen, in dem vorgeschlagene Entscheidungen, Spikes und die Ratschläge dazu besprochen werden. Es bietet Rat und Transparenz, entscheidet aber selbst nicht. Kapitel 11
Architecture Decision Record (ADR): Ein kurzes Dokument, das eine wesentliche Entscheidung festhält: ihren Kontext, die erwogenen Optionen, die Entscheidung, ihren Status und ihre Konsequenzen. Kapitel 1
Architecture Review Board: Ein ständiges Gremium erfahrener Architekten, das wesentliche Entwürfe prüft und genehmigt, meist an festgelegten Punkten eines Projekts. Es kann unabhängiges Urteil einbringen, wird aber oft zu einem langsamen Gate. Kapitel 11
Architecture Sinkhole: Ein Anti-Pattern in Schichtensystemen, bei dem Anfragen durch Schichten laufen, die sie nur weiterreichen, was Code und Verzögerung hinzufügt, ohne Verhalten hinzuzufügen. Kapitel 5
Architektur-Governance: Die Praktiken, mit denen eine Organisation sicherstellt, dass wesentliche technische Entscheidungen gut getroffen werden, mit ihren Zielen übereinstimmen und tatsächlich befolgt werden, einschließlich der Frage, wer wie und mit welchen Prüfungen entscheidet. Kapitel 11
Architektur-Kata: Eine Übungsaufgabe, entwickelt von Ted Neward, bei der kleine Teams für eine kurze, bewusst unvollständige Aufgabenstellung eine Architektur entwerfen und diese dann vor anderen präsentieren und verteidigen. Kapitel 11
Architekturansatz: Eine wesentliche Designentscheidung oder Kombination von Entscheidungen, etwa ein Stil, ein Muster oder eine Taktik, mit der die Architektur ein Qualitätsmerkmal erreicht: zum Beispiel ein Event Broker mit Outbox oder eine Warm-Standby-Region. Kapitel 11
Architekturbeschreibung: Ein Arbeitsergebnis (Dokumente, Diagramme, Modelle, Entscheidungsdokumente), das eine Architektur ausdrückt. Die Architektur existiert unabhängig davon, ob sie beschrieben ist; die Beschreibung ist das Mittel, mit dem Menschen sie teilen. Kapitel 1
Architekturbeschreibungsrahmen: In ISO/IEC/IEEE 42010:2022 eine etablierte Menge von Konventionen zur Erstellung von Architekturbeschreibungen, etwa Blickwinkel (Viewpoints), Vorlagen und Regeln. Kapitel 4
Architekturbewertung: Eine strukturierte Untersuchung einer Architektur vor oder nach ihrer Umsetzung, um herauszufinden, ob ihre Entscheidungen es dem System ermöglichen, seine Geschäftsziele und Qualitätsanforderungen zu erfüllen, und wo sie diese Ziele gefährden. Kapitel 11
Architekturdrift: Änderungen, die ohne Kenntnis der beabsichtigten Architektur vorgenommen werden und das System, ohne ausdrückliche Regeln zu verletzen, von ihr wegbewegen und ihre Konzepte verwischen. Kapitel 1
Architekturerosion: Der allmähliche Verfall eines Systems, wenn Änderungen seine beabsichtigte Architektur verletzen, zum Beispiel durch das Umgehen von Schichten oder das Hinzufügen verbotener Abhängigkeiten. Kapitel 1
Architekturmerkmal: Der Begriff von Richards und Ford für ein Qualitätsmerkmal, das die Architektur unterstützen muss, etwa Skalierbarkeit, Deploybarkeit oder Fehlertoleranz. Kapitel 5
Architekturmuster: Eine dokumentierte, wiederverwendbare Lösung für ein wiederkehrendes strukturelles Problem in einem benannten Kontext, die die Teile, ihre Verantwortlichkeiten und ihre Beziehungen benennt. Wird oft gleichbedeutend mit Stil verwendet. Kapitel 5
Architekturprinzip: Eine dauerhafte Regel, die Architekturentscheidungen leitet, im TOGAF-Stil formuliert mit einem Namen, einer Aussage, einer Begründung und ihren Auswirkungen. Kapitel 11
Architekturquantum: Ein unabhängig deploybarer Teil eines Systems mit hoher funktionaler Kohäsion, der alles umfasst, was er zum Laufen braucht, etwa seine Datenbank; der Bereich, in dem ein bestimmter Satz von Architekturmerkmalen gilt. Kapitel 5
Architekturrelevant: Bezeichnet eine Entscheidung oder Anforderung, die später teuer zu ändern ist, viele Teile eines Systems betrifft oder ein zentrales Qualitätsmerkmal bestimmt. Kapitel 1
Architekturrelevante Anforderung (ASR): Eine Anforderung, die messbare Auswirkungen auf die Architektur eines Systems hat: Würde sie sich ändern, müsste sich die Struktur ändern. Die meisten ASRs sind Qualitätsmerkmale oder Randbedingungen. Kapitel 2
Architekturschulden: Technische Schulden in der Struktur eines Systems, etwa falsche Grenzen, eine gemeinsam genutzte Datenbank oder zyklische Abhängigkeiten; sie sind teuer zu tilgen, weil sie viele Teile berühren. Kapitel 1
Architekturstil: Eine benannte Familie von Architekturen, definiert durch die Arten von Elementen und Konnektoren, die sie verwendet, und durch die Regeln, wie diese kombiniert werden dürfen, etwa Schichtenarchitektur oder Pipes and Filters. Kapitel 5
Architekturtest: Ein automatisierter Test, der den Build scheitern lässt, wenn Code eine Strukturregel verletzt, etwa eine verbotene Abhängigkeit zwischen Schichten oder Modulen; Werkzeuge dafür sind unter anderem ArchUnit und import-linter. Kapitel 5
Architekturtreiber: Ein Ziel, eine Qualitätsanforderung oder eine Randbedingung, die die Architektur wesentlich prägt. Kapitel 2
Artefakt-Repository: Ein Speicher für gebaute, versionierte Ergebnisse wie Container-Images und Pakete, aus dem jede Umgebung dieselbe Datei deployt. Kapitel 10
Asymmetrische Kryptografie (Public-Key-Kryptografie): Kryptografie mit einem Schlüsselpaar: einem öffentlichen Schlüssel, den jeder besitzen darf, und einem geheim gehaltenen privaten Schlüssel; verwendet für Schlüsselaustausch, digitale Signaturen und Zertifikate. Kapitel 8
AsyncAPI: Eine maschinenlesbare Spezifikation zur Beschreibung nachrichtengesteuerter APIs: der Kanäle, der Operationen, die auf ihnen senden oder empfangen, und der Nachrichtenschemas. Kapitel 6
Asynchrone Kommunikation: Eine Interaktion, bei der der Sender eine Nachricht an einen Vermittler wie einen Message Broker übergibt und weiterarbeitet, ohne zu warten; der Empfänger verarbeitet sie, wenn er bereit ist. Kapitel 6
Asynchrones Messaging: Kommunikation, bei der der Sender eine Nachricht irgendwo ablegt, damit der Empfänger sie später verarbeitet, und weiterarbeitet, ohne auf eine Antwort zu warten. Kapitel 0
At-least-once-Zustellung: Eine Garantie, dass jede Nachricht verarbeitet wird, möglicherweise mehr als einmal; Duplikate muss der Empfänger behandeln. Kapitel 6
ATAM (Architecture Tradeoff Analysis Method): Die szenariobasierte Bewertungsmethode des SEI (Kazman, Klein und Clements, 2000). In neun Schritten über zwei Treffen setzt sie geschäftliche Treiber und priorisierte Szenarien in Beziehung zu Architekturansätzen und liefert Risiken, Nicht-Risiken, Sensitivitätspunkte, Trade-off-Punkte und Risikothemen. Kapitel 11
Atomare Fitness Function: Eine Fitness Function, die ein Architekturmerkmal in einem einzigen Kontext prüft, etwa ein Test, der Importe zwischen zwei Paketen verbietet. Kapitel 11
Attributbasierte Zugriffskontrolle (ABAC): Zugriffsentscheidungen durch Auswertung einer Richtlinie über Attribute des Benutzers, der Ressource, der Aktion und des Kontexts, etwa Land, Datenklassifizierung oder Tageszeit. Kapitel 8
Audit-Trail: Eine vollständige, chronologische und manipulationssichere Aufzeichnung festgelegter Aktionen, die zeigt, wer was wann getan hat, und der Nachvollziehbarkeit der Verantwortung dient. Kapitel 8
Aufbewahrungsplan: Eine dokumentierte Liste, die festhält, wie lange jede Datenkategorie aufbewahrt wird, warum und was am Ende dieses Zeitraums mit ihr geschieht. Kapitel 8
Auftragsverarbeiter: Eine Organisation, die personenbezogene Daten im Auftrag eines Verantwortlichen verarbeitet, nach dessen Weisungen und auf Grundlage eines Vertrags, etwa ein Cloud-Anbieter für SMS oder E-Mail. Kapitel 8
Aufwärtskompatibilität: Eine Schemaänderung ist aufwärtskompatibel, wenn Code, der das alte Schema verwendet, weiterhin Daten lesen kann, die mit dem neuen geschrieben wurden, meist indem er unbekannte Felder ignoriert. Kapitel 7
Ausfall (Failure): Ein Ereignis, bei dem der von einem System erbrachte Dienst für seine Benutzer erkennbar von dem abweicht, was er sein sollte. Kapitel 2
Auslastung: Der Anteil der Zeit, in der eine Ressource beschäftigt ist, meist als ρ (rho) geschrieben. Ein Server, der 40 Anfragen pro Sekunde mit je 20 ms Arbeit bearbeitet, ist zu 80 % ausgelastet. Kapitel 2
Authentifizierung: Die Prüfung, ob ein Benutzer oder System der- oder dasjenige ist, das es zu sein behauptet, zum Beispiel durch ein Passwort, einen Passkey oder ein Zertifikat. Kapitel 8
Automation Bias: Die Neigung von Menschen, Empfehlungen eines automatisierten Systems ohne ausreichende Prüfung zu übernehmen, selbst wenn sie falsch sind. Kapitel 12
Automatisierte Canary-Analyse: Statistischer Vergleich der Metriken eines Canary mit denen einer Baseline, die die alte Version ausführt; die Pipeline nutzt ihn, um ohne menschliches Urteil freizugeben oder zurückzurollen. Kapitel 10
Autorisierung: Die Entscheidung, ob ein authentifizierter Benutzer oder ein authentifiziertes System eine bestimmte Aktion auf einer bestimmten Ressource ausführen darf. Kapitel 8
Autoscaling: Die automatische Änderung der Zahl der Instanzen bei wechselnder Last: reaktiv anhand einer Metrik, nach Zeitplan oder vorausschauend anhand einer Prognose. Kapitel 9
Availability Zone: Eine von mehreren physisch getrennten Gruppen von Rechenzentren innerhalb einer Cloud-Region, jede mit eigener Stromversorgung, Kühlung und Netzwerkanbindung, nahe genug beieinander für schnelle Verbindungen. Kapitel 0

B

Backend as a Service (BaaS): Vollständig verwaltete Dienste von Drittanbietern, etwa Authentifizierung, Datenbanken, Speicher und Messaging, die serverseitige Komponenten ersetzen, die eine Organisation sonst selbst bauen und betreiben müsste. Kapitel 6
Backend for Frontend (BFF): Eine serverseitige API, die für eine bestimmte Art von Client gebaut ist, etwa die mobile App, sodass jeder Client Operationen und Daten erhält, die auf seine Bedürfnisse zugeschnitten sind. Kapitel 3
Backend for Frontend (BFF): Ein schlankes Backend, das für eine bestimmte Art von Client gebaut ist, etwa die mobile App, und Services aufruft und deren Daten für diesen Client aufbereitet. Kapitel 6
Backfill: Das Befüllen einer neuen Spalte oder Tabelle mit Werten für bestehende Zeilen, meist in kleinen Stapeln, damit das Live-System nicht gestört wird. Kapitel 7
Background Worker: Ein Prozess, der langsame oder schubweise anfallende Aufträge wie E-Mails oder Berichte aus einer Queue nimmt und sie außerhalb der Anfrage verarbeitet, die sie erzeugt hat. Kapitel 5
Backing Service: Jeder Dienst, den eine Anwendung über das Netzwerk nutzt, etwa eine Datenbank, Queue, ein Cache oder eine E-Mail-API, behandelt als angebundene Ressource, die sich per Konfiguration austauschen lässt. Kapitel 10
Backpressure: Ein Mechanismus, mit dem ein langsamer Consumer einen schnellen Producer bremsen kann, statt Puffer und Queues unbegrenzt wachsen zu lassen. Kapitel 5
Backup: Eine getrennt vom Original aufbewahrte Kopie von Daten, damit sie nach Verlust, Beschädigung oder Löschung wiederhergestellt werden können. Kapitel 0
Bandbreite: Wie viele Daten eine Verbindung pro Sekunde übertragen kann, etwa 100 Megabit pro Sekunde. Hohe Bandbreite verringert die Latenz nicht. Kapitel 0
Barrierefreiheit: Das Maß, in dem Menschen mit Behinderungen, auch solche, die assistive Technologien wie Screenreader nutzen, ein Produkt verwenden können. Kapitel 2
Batch-Inferenz: Die gemeinsame, asynchrone Verarbeitung vieler Modellanfragen zu geringeren Kosten pro Anfrage, aber mit längerer Wartezeit auf die Ergebnisse. Kapitel 12
Baustein: In arc42 jeder Teil der statischen Struktur eines Systems, etwa ein Subsystem, Service, eine Komponente oder ein Modul, dargestellt in der Bausteinsicht. Kapitel 4
Bedienzeit (Service Time): Die Zeit, die eine Ressource tatsächlich mit der Bearbeitung einer Anfrage verbringt, ohne die Zeit, die die Anfrage auf diese Ressource wartet. Kapitel 2
Bedrohungsmodellierung: Eine strukturierte Art, zu einem Entwurf zu fragen, was wir bauen, was schiefgehen kann, was wir dagegen tun und ob wir gute Arbeit geleistet haben. Kapitel 8
Beitragender Faktor: Eine von mehreren Bedingungen, die einen Incident gemeinsam möglich gemacht oder verschlimmert haben; Reviews suchen nach vielen beitragenden Faktoren statt nach einer einzigen Grundursache. Kapitel 9
Benötigte Schnittstelle: In einem UML-Komponentendiagramm eine Schnittstelle, die eine Komponente von einer anderen Komponente bereitgestellt braucht, dargestellt als Halbkreis (Socket). Kapitel 4
Bereitgestellte Schnittstelle: In einem UML-Komponentendiagramm eine Schnittstelle, die eine Komponente anderen anbietet, dargestellt als kleiner Kreis (Ball) an einem Stiel. Kapitel 4
Bestärkendes Lernen (Reinforcement Learning): Maschinelles Lernen, bei dem ein Agent Aktionen ausführt und aus einem Belohnungssignal lernt statt aus richtigen Antworten. Kapitel 12
Betrachtungsgegenstand (Entity of Interest): In ISO/IEC/IEEE 42010:2022 das, dessen Architektur beschrieben wird: ein Softwaresystem, ein System von Systemen, eine Produktlinie oder ein Unternehmen. Kapitel 4
Betriebssicherheit (Safety): Freiheit von unvertretbaren Risiken eines Schadens für Menschen, Sachwerte oder die Umwelt, der durch das System verursacht wird, unabhängig davon, ob jemand böswillig handelt. Kapitel 2
Betriebssystem: Die Software, die die Hardware eines Computers verwaltet und zwischen Programmen aufteilt: CPU-Zeit, Arbeitsspeicher, Dateien, Netzwerk und Sicherheit. Beispiele sind Linux, Windows, macOS, Android und iOS. Kapitel 0
Beziehung: Eine Verbindung zwischen Elementen, etwa dass ein Modul ein anderes nutzt, ein Service einen anderen aufruft oder ein Service auf einem Server deployt ist. Kapitel 1
Beziehungsbasierte Zugriffskontrolle (ReBAC): Zugriffsentscheidungen auf Grundlage von Beziehungen zwischen Benutzern und Objekten (Eigentümer von, Mitglied von, arbeitet bei), gespeichert als Graph; Googles Zanzibar (2019) ist das bekannteste Beispiel. Kapitel 8
Bibliothek: Wiederverwendbarer Code, den jemand anderes geschrieben hat und den Ihr Code bei Bedarf aufruft, etwa eine Bibliothek für Datumsangaben oder für den E-Mail-Versand. Kapitel 0
Big Ball of Mud: Ein System ohne erkennbare Struktur, in dem fast alles von allem anderen abhängt; der Name stammt von Brian Foote und Joseph Yoder (1997). Kapitel 5
Big Design Up Front (BDUF): Ein Ansatz, bei dem Architektur und Design vollständig im Detail ausgearbeitet werden, bevor die Implementierung beginnt. Kapitel 1
Big-Bang-Neuentwicklung: Die Ablösung eines Systems, indem ein neues von Grund auf gebaut und auf einen Schlag umgestellt wird; gilt weithin als riskant, weil der Nutzen erst am Ende eintritt und verborgenes Verhalten leicht verloren geht. Kapitel 11
Bindungszeitpunkt: Der Zeitpunkt, zu dem eine Entscheidung festgelegt wird: beim Schreiben des Codes, beim Build, beim Deployment, beim Start oder während das System läuft. Kapitel 2
Bit: Eine Binärziffer, 0 oder 1: die kleinste Informationseinheit, die ein Computer speichert. Kapitel 0
Blameless Culture: Ein Ansatz, bei dem Menschen, die an einem Incident beteiligt waren, ohne Angst vor Bestrafung beschreiben können, was sie getan haben und warum, damit die Organisation lernt, wie das System wirklich funktioniert. Kapitel 9
Blast Radius: Wie viel vom System und wie viele Benutzer ein Ausfall, eine Änderung oder ein Experiment betreffen kann; Chaos-Experimente halten ihn bewusst klein. Kapitel 9
Blickwinkel (Viewpoint): Eine Festlegung, wie eine bestimmte Art von Architektursicht erstellt und gelesen wird: welchen Stakeholdern und Anliegen sie dient und welche Modellierungskonventionen sie verwendet. Kapitel 1
Blue-Green-Deployment: Der Betrieb zweier vollständiger Produktionsumgebungen, wobei der gesamte Traffic auf einen Schlag von der alten (Blue) auf die neue (Green) umgeschaltet wird und die alte für ein sofortiges Zurückschalten bereitbleibt. Kapitel 10
BM25: Eine klassische Ranking-Funktion für Schlüsselwörter, die Dokumente danach bewertet, wie oft sie die Begriffe der Anfrage enthalten, seltene Begriffe stärker gewichtet und die Dokumentlänge normalisiert. Kapitel 12
Bounded Context: Eine ausdrückliche Grenze, innerhalb derer ein Domänenmodell und seine Ubiquitous Language einheitlich gelten; außerhalb davon können dieselben Wörter etwas anderes bedeuten. Kapitel 5
Branch: Ein separater Entwicklungszweig in der Versionskontrolle, in dem an einer Änderung gearbeitet wird, ohne die Hauptlinie zu beeinflussen, bis sie zum Mergen bereit ist. Kapitel 0
Branch by Abstraction: Eine Technik für große Änderungen innerhalb einer Codebasis: Man stellt eine Abstraktion vor den zu ersetzenden Teil, stellt die Aufrufer auf sie um, baut die neue Implementierung dahinter, schaltet um und entfernt die alte, wobei das System durchgehend releasefähig bleibt. Kapitel 11
Breaking Change: Eine Änderung an einer API, die bestehenden, korrekten Client-Code nicht mehr funktionieren lässt, etwa das Umbenennen oder Entfernen eines Felds. Kapitel 0
Breakpoint-Test: Ein Performance-Test, der die Last stetig steigert, bis das System zusammenbricht, um seine maximale Kapazität und seinen ersten Engpass zu finden. Kapitel 9
Broker-Topologie: Eine ereignisgesteuerte Topologie ohne zentralen Koordinator: Prozessoren reagieren auf Ereignisse und veröffentlichen weitere Ereignisse, sodass sich der Ablauf aus ihren Reaktionen ergibt. Kapitel 6
Bruchlinie (Fracture Plane): Eine natürliche Nahtstelle, an der sich ein Softwaresystem so aufteilen lässt, dass jeder Teil zu einem Team passt, zum Beispiel ein Bounded Context, eine regulatorische Grenze, ein anderer Änderungsrhythmus oder ein anderes Risikoprofil. Kapitel 11
Bug: Ein Fehler in Software, durch den sie sich anders verhält als beabsichtigt, vom Absturz bis zu einer stillschweigend falschen Antwort. Kapitel 0
Bug-Bounty: Ein Programm, das externe Forschende für die Meldung gültiger Sicherheitslücken über ein vereinbartes Verfahren bezahlt. Kapitel 8
Build once, deploy many: Die Regel, dass eine Änderung genau einmal zu einem unveränderlichen Artefakt gebaut wird und dasselbe Artefakt durch alle Umgebungen befördert wird, wobei sich nur die Konfiguration unterscheidet. Kapitel 10
Build, Release, Run: Die strikte Trennung zwischen dem Umwandeln von Code in ein Artefakt (Build), dessen Kombination mit der Konfiguration einer Umgebung (Release) und seiner Ausführung (Run). Kapitel 10
Bulkhead: Die Aufteilung von Ressourcen wie Thread-Pools, Connection-Pools oder Instanzen, damit ein Ausfall oder eine Überlast in einem Teil nicht die Ressourcen der anderen aufbrauchen kann. Kapitel 9
Burn Rate: Wie schnell ein Error Budget verbraucht wird, im Verhältnis zu der Rate, die es genau am Ende des Zeitfensters aufbrauchen würde; eine Burn Rate von 1 verbraucht es in genau einem Zeitfenster. Kapitel 9
Business Case: Eine strukturierte Begründung für eine Investition, die das Problem, die Optionen (einschließlich Nichtstun), ihre Kosten, Nutzen und Risiken sowie eine Empfehlung darlegt, die Entscheidungsträger mit anderen Verwendungen des Geldes vergleichen können. Kapitel 11
Byte: Eine Gruppe von acht Bits, die 256 verschiedene Werte aufnehmen kann. Datei- und Speichergrößen werden in Bytes gezählt (Kilobyte, Megabyte, Gigabyte). Kapitel 0
Bytecode: Kompakte Anweisungen für eine virtuelle Maschine statt für eine echte CPU. Java und Python kompilieren Quellcode zu Bytecode, den ihre Laufzeitumgebungen dann auf jeder unterstützten Maschine ausführen. Kapitel 0

C

C4-Modell: Der Ansatz von Simon Brown für Architekturdiagramme: eine Hierarchie aus Systemkontext-, Container-, Komponenten- und Codediagrammen sowie einigen ergänzenden Diagrammen. Kapitel 4
Cache: Eine Kopie von Daten an einem schneller erreichbaren Ort, damit wiederholte Anfragen langsame Arbeit vermeiden. Sie tauscht zusätzlichen Speicher und das Risiko veralteter Daten gegen Geschwindigkeit. Kapitel 0
Cache Stampede: Ein Ansturm von Anfragen, die alle im selben Moment den Cache verfehlen, meist wenn ein beliebter Eintrag abläuft, und alle gleichzeitig die langsamere Quelle treffen; eng verwandt mit dem Thundering-Herd-Problem. Kapitel 7
Cache-Aside: Ein Caching-Muster, bei dem die Anwendung den Cache prüft, bei einem Fehltreffer aus der Datenbank lädt und das Ergebnis selbst in den Cache legt; auch Lazy Loading genannt. Kapitel 7
Cache-Invalidierung: Das Entfernen einer zwischengespeicherten Kopie oder ihre Kennzeichnung als veraltet, wenn sich die Originaldaten ändern, damit spätere Lesezugriffe den neuen Wert holen. Kapitel 7
Cache-Trefferquote: Der Anteil der Abfragen, die der Cache aus seinem eigenen Inhalt beantworten kann; der Rest sind Fehltreffer (Misses), die an die langsamere Quelle gehen. Kapitel 7
Canary Release: Ein kleiner Anteil des echten Traffics wird zuerst an eine neue Version geleitet, ihr Verhalten mit der alten Version verglichen und der Anteil nur erhöht, wenn sie fehlerfrei läuft. Kapitel 10
CAP-Theorem: Das Ergebnis, 2000 von Eric Brewer vermutet und 2002 von Gilbert und Lynch bewiesen, dass ein repliziertes System während einer Netzwerkpartition nicht zugleich linearisierbar und für jede Anfrage verfügbar sein kann. Kapitel 6
Carbon-Aware Computing: Software so zu betreiben, dass sie mehr leistet, wenn der Strom sauberer ist, und weniger, wenn er schmutziger ist, indem Arbeit zeitlich oder örtlich verschoben oder die Nachfrage gesteuert wird. Kapitel 11
CBAM (Cost Benefit Analysis Method): Eine Methode des SEI, die auf der ATAM aufbaut: Sie schätzt den Nutzen jeder Architekturstrategie anhand des Utility-Gewinns für priorisierte Szenarien und teilt ihn durch ihre Kosten, um das Kosten-Nutzen-Verhältnis zu vergleichen. Kapitel 11
Change Coupling: Zwei oder mehr Dateien oder Komponenten, die sich tendenziell in denselben Commits ändern, was eine Abhängigkeit offenlegt, die im Code möglicherweise nicht sichtbar ist. Kapitel 1
Change Data Capture (CDC): Das Auslesen des eigenen Änderungs- oder Replikationslogs einer Datenbank, um jedes festgeschriebene Insert, Update und Delete an andere Systeme zu streamen. Debezium ist eine weit verbreitete Open-Source-Plattform für CDC. Kapitel 6
Chaos Engineering: Experimente an einem System, idealerweise in Produktion und unter Kontrolle, bei denen realistische Ausfälle eingespeist werden, um Vertrauen zu gewinnen, dass es turbulenten Bedingungen standhält. Kapitel 9
Chaos-Experiment: Ein kontrollierter Test, der einen echten Ausfall herbeiführt, etwa das Beenden einer Instanz oder das Verlangsamen einer Abhängigkeit, um eine formulierte Hypothese darüber zu prüfen, wie das System seinen Normalzustand (Steady State) hält. Kapitel 11
Charakterisierungstest: Ein Test, der festhält, was bestehender Code tatsächlich tut, und nicht, was er tun sollte, damit Änderungen am aktuellen Verhalten überprüft werden können. Der Begriff stammt von Michael Feathers. Kapitel 11
Chargeback: Die Belastung des Budgets jedes Teams oder Produkts mit den ihm zugeordneten Kosten, sodass die Ausgaben in seiner eigenen Rechnung erscheinen. Kapitel 10
Choreografie: Die Koordination eines mehrstufigen Prozesses dadurch, dass die Beteiligten auf die Ereignisse der anderen reagieren, ohne dass eine einzelne Komponente die Steuerung übernimmt. Kapitel 6
Chunking: Das Aufteilen von Dokumenten in Abschnitte, die klein genug sind, um sie zu indexieren, abzurufen und in einen Prompt einzufügen, idealerweise entlang der eigenen Struktur der Dokumente. Kapitel 12
CI/CD-Pipeline: Die automatisierte Abfolge von Schritten (Build, Test, Deployment auf Staging, Deployment in Produktion), die jede Änderung auf dem Weg zu den Benutzern durchläuft. Kapitel 0
CIA-Triade: Die drei klassischen Ziele der Informationssicherheit: Vertraulichkeit (nur Berechtigte können lesen), Integrität (keine unbefugten Änderungen) und Verfügbarkeit (nutzbar, wenn benötigt). Kapitel 2
Circuit Breaker: Eine Hülle um Aufrufe an eine Abhängigkeit, die nach genügend Fehlschlägen eine Weile keine Aufrufe mehr durchlässt und sofort fehlschlägt und dann Testaufrufe durchlässt, um die Erholung zu prüfen (Michael Nygard, 2007). Kapitel 9
Client-Server-Modell: Eine Anordnung, bei der Clients (etwa Browser oder mobile Apps) Anfragen senden und Server, die gemeinsame Daten und Logik halten, antworten. Kapitel 0
Cloud-Computing: Das Mieten von Rechenressourcen (Server, Speicher, Datenbanken und andere Dienste) über das Internet nach Bedarf, wobei man für die tatsächliche Nutzung bezahlt. Kapitel 0
Cloud-native: Ein Ansatz, Software als lose gekoppelte, automatisierte, beobachtbare und resiliente Systeme zu bauen und zu betreiben, die programmatisch und wiederholbar in öffentlichen, privaten oder hybriden Clouds deployt werden. Er beschreibt, wie ein System gebaut ist, nicht, wo es läuft. Kapitel 10
Cloud-Repatriierung: Die Rückverlagerung von Workloads aus einer Public Cloud auf eigene oder in Colocation betriebene Hardware, meist weil eine gleichmäßige Last den Eigenbetrieb günstiger macht. Kapitel 10
Code-Review: Die Prüfung einer vorgeschlagenen Codeänderung durch Kollegen vor dem Mergen, um Mängel zu finden, Wissen zu teilen und das Design einheitlich zu halten. Kapitel 0
Command: Eine Nachricht, die einen bestimmten Handler auffordert, etwas zu tun, etwa AuthorisePayment. Anders als ein Ereignis kann sie abgelehnt werden. Kapitel 6
Command-Query Separation (CQS): Das Prinzip von Bertrand Meyer, nach dem eine Methode entweder den Zustand ändern (ein Command) oder eine Antwort zurückgeben (eine Query) soll, aber nicht beides. Kapitel 7
Commit: Ein gespeicherter Schnappschuss von Änderungen in der Versionskontrolle, mit Autor, Zeitstempel und einer Nachricht, die die Änderung erklärt. Kapitel 0
Common Closure Principle (CCP): Klassen, die sich aus denselben Gründen und zu denselben Zeitpunkten ändern, gehören in dieselbe Komponente; das Single Responsibility Principle, angewandt auf Komponenten. Kapitel 3
Common Reuse Principle (CRP): Klassen, die zusammen verwendet werden, gehören zusammen, und Nutzer einer Komponente sollten nicht gezwungen sein, von Klassen abzuhängen, die sie nicht verwenden. Kapitel 3
Competing Consumers: Ein Muster, bei dem mehrere Worker aus derselben Queue lesen und jede Nachricht nur von einem von ihnen verarbeitet wird, sodass der Durchsatz durch zusätzliche Worker steigt. Kapitel 9
Compiler: Ein Programm, das Quellcode vor der Ausführung in eine andere Form übersetzt, etwa in Maschinencode oder Bytecode. Kapitel 0
Complicated-Subsystem-Team: Ein Team, das einen Teil des Systems verantwortet, der seltenes Spezialwissen erfordert, etwa einen Optimierungsalgorithmus oder einen Video-Codec, damit Stream-aligned Teams ihn nutzen können, ohne ihn beherrschen zu müssen. Kapitel 11
Composition Root: Die einzige Stelle, meist der Startcode des Programms, an der konkrete Adapter erzeugt und in die Anwendung eingesteckt werden. Kapitel 5
Confused Deputy: Ein Programm, das Befugnisse besitzt und dazu verleitet wird, sie im Auftrag von jemandem einzusetzen, dem diese Befugnisse fehlen (Norm Hardy, 1988). Kapitel 12
Connascence: Zwei Elemente sind connascent, wenn eine Änderung an einem eine Änderung am anderen erfordern würde, damit das System korrekt bleibt. Eine feinere Art, Kopplung zu beschreiben, eingeführt von Meilir Page-Jones. Kapitel 3
Connection Draining: Das Stoppen neuer Anfragen an eine Instanz, die entfernt wird, während bereits laufende Anfragen zu Ende bearbeitet werden, sodass beim Herunterskalieren und bei Deployments keine Arbeit verloren geht. Kapitel 9
Consumer Group: Eine Gruppe von Consumern, die sich die Arbeit des Lesens eines Topics teilen: Jede Partition wird von einem Mitglied gelesen, und jede Gruppe führt ihre eigenen Offsets. Kapitel 6
Consumer-Driven Contract: Ein Vertrag, der sich daraus zusammensetzt, was jeder Consumer von der API eines Providers tatsächlich nutzt; der Provider führt die Erwartungen aller Consumer in seinem eigenen Build aus und weiß so, welche Änderungen wen beeinträchtigen würden. Kapitel 6
Container: Eine paketierte Anwendung mit ihren Bibliotheken und Einstellungen, ausgeführt als isolierter Prozess, der sich den Betriebssystemkern des Hosts teilt. Leichtgewichtiger und schneller startend als eine virtuelle Maschine. Kapitel 0
Container (C4): Im C4-Modell eine separat ausführbare oder deploybare Einheit, die Code ausführt oder Daten speichert, etwa eine Web-App, eine mobile App, ein Service oder eine Datenbank. Es ist kein Docker-Container. Kapitel 4
Container-Image: Ein schreibgeschütztes, versioniertes Paket mit einer Anwendung und allem, was sie zum Laufen braucht, aus dem sich überall identische Container starten lassen. Kapitel 0
Container-Orchestrierung: Das automatische Verteilen von Containern auf Maschinen und ihr Am-Laufen-Halten: Neustart nach Ausfällen, Skalierung, Ausrollen neuer Versionen und Anbindung an Netzwerke und Speicher. Kapitel 10
Containerdiagramm: Ein C4-Diagramm, das die Apps, Services und Datenspeicher innerhalb eines Systems mit ihren Technologien und ihrer Kommunikation zeigt. Kapitel 4
Containers as a Service (CaaS): Ein Cloud-Dienst, der Container-Images für Sie ausführt, entweder als verwaltetes Kubernetes oder als serverlose Container-Plattform, bei der Sie die Maschinen nie sehen. Kapitel 10
Content Delivery Network (CDN): Ein Netz von Servern an vielen Standorten, das Kopien von Inhalten wie Bildern, Skripten und Videos nahe bei den Benutzern vorhält, damit sie schneller laden und der Ursprungsserver weniger Arbeit hat. Kapitel 0
Context Map: Eine Darstellung der Bounded Contexts eines Systems und ihrer Beziehungen, etwa Customer-Supplier oder Anticorruption Layer, die sowohl Integrations- als auch Teambeziehungen abdeckt. Kapitel 5
Continuous Delivery: Software stets in einem releasefähigen Zustand halten, sodass jede Version, die die automatisierte Pipeline besteht, auf Knopfdruck in Produktion gebracht werden kann. Kapitel 0
Continuous Deployment: Das automatische Ausliefern jeder Änderung, die die Pipeline besteht, in die Produktion, ohne manuellen Freigabeschritt. Kapitel 0
Continuous Integration (CI): Die Praxis, die Änderungen aller Entwicklerinnen und Entwickler häufig, mindestens täglich, in die gemeinsame Hauptlinie zu integrieren, wobei ein automatisierter Build und Tests jede Änderung prüfen. Kapitel 0
Contract Testing: Das isolierte Testen jeder Seite einer Integration gegen eine gemeinsame Beschreibung ihrer Interaktionen, statt beide für End-to-End-Tests gemeinsam zu deployen. Kapitel 6
Control Plane: Die Komponenten, die Entscheidungen für einen Cluster oder ein System treffen (in Kubernetes: API-Server, etcd, Scheduler und Controller), im Gegensatz zu den Knoten, auf denen die Workloads laufen. Kapitel 10
Cooldown (Stabilisierungsfenster): Ein Zeitraum nach einer Skalierungsaktion, in dem der Autoscaler wartet, bevor er erneut handelt, damit die Wirkung der letzten Änderung gemessen werden kann. Kapitel 9
Coordinated Omission: Ein von Gil Tene benannter Messfehler, bei dem ein Lastgenerator auf langsame Antworten wartet, bevor er weitere Anfragen sendet, und so die Verzögerungen nie erfasst, die echte Benutzer erlitten hätten. Kapitel 9
Core Domain: Die Subdomäne, die dem Unternehmen seinen Wettbewerbsvorteil verschafft und deshalb die besten Leute, die sorgfältigste Modellierung und Code verdient, der dem Unternehmen selbst gehört. Kapitel 5
Cost of Delay: Der Wert, der für jede Zeiteinheit verloren geht, in der eine Arbeit nicht geliefert wird; Don Reinertsen machte ihn als Mittel zur wirtschaftlichen Priorisierung von Arbeit bekannt. Kapitel 11
Counter: Eine Metrik, deren Wert nur steigt (oder bei einem Neustart auf null zurückgesetzt wird), etwa die Gesamtzahl bedienter Anfragen; meist betrachtet man ihre Zuwachsrate. Kapitel 9
CPU (Prozessor): Die zentrale Verarbeitungseinheit: der Chip, der die Anweisungen eines Programms ausführt, einen einfachen Schritt nach dem anderen, milliardenfach pro Sekunde. Moderne CPUs haben mehrere Kerne, die parallel arbeiten. Kapitel 0
CQRS: Command Query Responsibility Segregation: getrennte Modelle, oft auch getrennte Speicher, für das Ändern von Daten und für das Lesen. Kapitel 6
Crypto-Shredding: Daten unlesbar machen, indem der Schlüssel vernichtet wird, mit dem sie verschlüsselt sind; verwendet, um personenbezogene Daten aus Logs und Backups zu löschen, die sich nicht bearbeiten lassen. Kapitel 7
Cursor-Paginierung: Das seitenweise Durchlaufen einer Sammlung, indem ein undurchsichtiges Token übergeben wird, das das zuletzt gesehene Element markiert, statt eines numerischen Offsets. Es bleibt schnell und stabil, wenn während des Blätterns Elemente hinzukommen. Kapitel 6
CVE: Common Vulnerabilities and Exposures: das Programm, das jeder öffentlich bekannten Schwachstelle eine eindeutige Kennung wie CVE-2021-44228 gibt. Kapitel 8
CVSS: Das von FIRST gepflegte Common Vulnerability Scoring System, das den Schweregrad einer bekannten Schwachstelle von 0 bis 10 bewertet; Version 4.0 wurde 2023 veröffentlicht. Kapitel 8
Cyberresilienz-Verordnung (CRA): Die Verordnung (EU) 2024/2847, die Cybersicherheitsanforderungen, den Umgang mit Schwachstellen und Meldepflichten für in der EU vertriebene Hardware- und Softwareprodukte festlegt. Kapitel 8

D

Dark Launching: Das Aufrufen neuen Backend-Verhaltens in Produktion mit echtem Traffic, wobei seine Ergebnisse vor den Benutzern verborgen bleiben, um Performance und Korrektheit vor einem sichtbaren Release zu testen. Kapitel 11
Dark Pattern: Eine Benutzeroberfläche, die Menschen zu Entscheidungen verleiten oder drängen soll, die sie sonst nicht treffen würden, etwa durch versteckte Kosten oder schwer kündbare Abonnements; Harry Brignull prägte den Begriff 2010 und nennt sie heute Deceptive Patterns. Kapitel 11
Data Lake: Ein großer, günstiger Speicher, meist Objektspeicher, der Rohdaten aus vielen Quellen in ihrer ursprünglichen Form für spätere Analysen aufbewahrt. Kapitel 7
Data Lineage: Eine Aufzeichnung darüber, woher ein Datum stammt und welche Transformationen es auf dem Weg durchlaufen hat. Kapitel 7
Data Mesh: Der Ansatz von Zhamak Dehghani für analytische Daten, bei dem Domänenteams ihre Daten als Produkte auf einer Self-Service-Plattform unter föderierter Governance verantworten und veröffentlichen. Kapitel 7
Data Warehouse: Eine für Analysen gebaute Datenbank, die bereinigte Daten aus vielen operativen Systemen zusammenführt und ihre Historie aufbewahrt. Kapitel 7
Datei: Eine benannte Folge von Bytes, die auf einem Datenträger gespeichert und vom Betriebssystem verwaltet wird, etwa ein Foto, eine Tabelle oder ein Log. Kapitel 0
Datenabfluss (Egress): Daten, die das Netzwerk eines Cloud-Anbieters verlassen oder zwischen seinen Zonen oder Regionen wechseln, was meist pro Gigabyte berechnet wird. Kapitel 10
Datenbank: Eine organisierte Sammlung von Daten, die so gespeichert ist, dass sie durchsucht, aktualisiert und konsistent gehalten werden kann, meist verwaltet von einem Datenbankmanagementsystem. Kapitel 0
Datenbank pro Service: Die Regel, dass jeder Service seine Daten besitzt und kein anderer Service sie direkt liest oder schreibt; andere nutzen die API des Eigentümers oder seine Ereignisse. Kapitel 6
Datenbankindex: Eine zusätzliche Datenstruktur, meist ein B-Baum, mit der die Datenbank Zeilen anhand des Werts einer Spalte findet, ohne die ganze Tabelle zu lesen. Sie beschleunigt Lesezugriffe, verlangsamt aber Schreibzugriffe und belegt Platz. Kapitel 0
Datenbankmanagementsystem (DBMS): Die Software, die eine Datenbank speichert und den Zugriff darauf steuert: Sie beantwortet Abfragen, setzt Regeln durch, bedient viele Benutzer gleichzeitig und stellt den Zustand nach Abstürzen wieder her. PostgreSQL und MySQL sind Beispiele. Kapitel 0
Datenflussdiagramm (DFD): Ein Diagramm aus externen Entitäten, Prozessen, Datenspeichern und den Datenflüssen zwischen ihnen, mit Vertrauensgrenzen quer über die Flüsse; das übliche Modell für die Bedrohungsmodellierung. Kapitel 8
Datenherkunft (Data Provenance): Der dokumentierte Ursprung und die Geschichte von Daten: woher sie stammen, unter welcher Lizenz oder Einwilligung und wie sie transformiert wurden. Kapitel 12
Datenhoheit: Die Regel, dass jedes Datum von genau einem Modul oder Service geschrieben wird, den andere fragen müssen, statt seinen Speicher direkt zu lesen oder zu ändern. Kapitel 3
Datenkollision: In einem replizierten In-Memory-Cache aktualisieren zwei Einheiten denselben Eintrag, bevor die Replikation die erste Aktualisierung verbreitet hat, sodass eine Aktualisierung die andere überschreibt. Kapitel 6
Datenprodukt: Ein von einem Domänenteam zur Nutzung durch andere veröffentlichter Datensatz mit Verantwortlichem, Dokumentation, Qualitätsgarantien und einer stabilen Schnittstelle. Kapitel 7
Datenresidenz: Eine Anforderung, dass bestimmte Daten nur in einem bestimmten Land oder einer bestimmten Region gespeichert und manchmal auch verarbeitet werden. Kapitel 2
Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen: Die Pflicht nach Artikel 25 DSGVO, Datenschutzgrundsätze durch geeignete Maßnahmen in Systeme einzubauen und durch Voreinstellung nur die für den jeweiligen Zweck erforderlichen Daten zu verarbeiten. Kapitel 8
Datenschutz-Folgenabschätzung (DSFA): Eine nach Artikel 35 DSGVO erforderliche Abschätzung vor einer Verarbeitung, die voraussichtlich ein hohes Risiko für Personen zur Folge hat; sie beschreibt die Verarbeitung, ihre Notwendigkeit, die Risiken und die Abhilfemaßnahmen. Kapitel 8
Datenstruktur: Eine Art, Daten im Speicher zu organisieren, etwa als Liste, Dictionary, Menge, Queue, Stack, Baum oder Graph, gewählt, damit die benötigten Operationen schnell sind. Kapitel 0
Datentyp: Die Art eines Werts, etwa eine ganze Zahl, eine Dezimalzahl, Text oder wahr/falsch, die bestimmt, welche Operationen darauf sinnvoll sind. Kapitel 0
Datenvertrag (Data Contract): Eine ausdrückliche, versionierte Vereinbarung zwischen einem Dateneigentümer und seinen Consumern über Schema, Bedeutung, Qualität, Aktualität, Zuständigkeit und die Ankündigung von Änderungen. Kapitel 7
Dead Letter Queue: Ein separater Ort, an dem Nachrichten, deren Verarbeitung wiederholt fehlschlägt, zur Untersuchung abgestellt werden, damit sie den übrigen Fluss nicht blockieren. Kapitel 5
Deadline-Weitergabe (Deadline Propagation): Die Weitergabe der für eine gesamte Anfrage verbleibenden Zeit an jeden nachgelagerten Aufruf, damit kein Service an einer Anfrage weiterarbeitet, die sein Aufrufer bereits aufgegeben hat. Kapitel 9
Defense in Depth: Das Schichten mehrerer unabhängiger Schutzmaßnahmen, sodass ein Angreifer, der eine überwindet, noch weiteren gegenübersteht, zum Beispiel eine Prüfung im Gateway, eine Prüfung im Service und die Verschlüsselung der Daten selbst. Kapitel 8
Dependency Injection: Einer Komponente die benötigten Kollaborateure (eine Datenbank, eine Uhr, ein Zahlungs-Gateway) von außen übergeben, statt sie diese selbst erzeugen zu lassen, damit sie sich austauschen lassen, zum Beispiel gegen Fakes in Tests. Kapitel 2
Dependency Inversion Principle (DIP): High-Level-Policy soll nicht von Low-Level-Details abhängen; beide sollen von Abstraktionen abhängen, und die Abstraktion soll der Policy-Seite gehören. Kapitel 3
Deploybarkeit: Wie schnell, sicher und vorhersehbar eine Änderung in Produktion gebracht und bei Bedarf wieder zurückgenommen werden kann. Kapitel 2
Deployment (Kubernetes): Ein Kubernetes-Objekt, das festlegt, wie viele identische Pods einer zustandslosen Anwendung laufen sollen, und neue Versionen schrittweise über ReplicaSets ausrollt. Kapitel 10
Deployment-Diagramm: Ein Diagramm (in C4 oder UML), das zeigt, wie Software in einer Umgebung auf Infrastruktur abgebildet wird, einschließlich Knoten, Replikaten und Netzwerkpfaden. Kapitel 4
Deployment-Einheit: Das, was als ein Stück gebaut, released und gestartet wird: zum Beispiel eine ausführbare Datei, ein Container-Image oder ein Webarchiv. Kapitel 5
Deployment-Kopplung: Eine Situation, in der zwei Teile gemeinsam oder in fester Reihenfolge ausgeliefert werden müssen, weil eine Änderung am einen den anderen bricht. Kapitel 3
Deployment-Pipeline: Die automatisierte Abfolge von Stufen (Build, Tests, Paketierung, Deployment, Verifikation), die jede Änderung auf dem Weg vom Commit bis in die Produktion durchläuft. Kapitel 10
Design by Contract: Die Methode von Bertrand Meyer, jede Operation mit Vorbedingungen, die der Aufrufer erfüllen muss, Nachbedingungen, die die Operation garantiert, und Invarianten, die immer gelten, zu spezifizieren. Kapitel 3
Design-Review (RFC-Review): Eine schriftliche Prüfung eines vorgeschlagenen Designdokuments oder Request for Comments, bei der Betroffene asynchron kommentieren, bevor das Design genehmigt und seine Entscheidungen festgehalten werden. Kapitel 11
Designdokument (RFC): Ein schriftlicher Vorschlag für eine wesentliche Änderung, der Problem, Ziele, Design und Alternativen behandelt und vor der Umsetzung zur Kommentierung in Umlauf gebracht wird. Kapitel 4
DevOps: Eine Kultur und eine Reihe von Praktiken, bei denen Entwicklung und Betrieb als Einheit arbeiten und die Verantwortung für Bau, Release und Betrieb von Software teilen, unterstützt durch Automatisierung und Messung. Kapitel 0
Diagrams as Code: Diagramme als Text in einer kleinen Sprache schreiben, etwa PlantUML, Mermaid, D2 oder Structurizr DSL, die ein Werkzeug anordnet und zeichnet. Kapitel 4
Dictionary (Map): Eine Datenstruktur, die Werte unter eindeutigen Schlüsseln speichert, sodass ein Wert direkt über seinen Schlüssel gefunden werden kann, meist in annähernd konstanter Zeit. Auch Map oder Hashtabelle genannt. Kapitel 0
Die sieben Rs (Seven Rs): Die Migrationsstrategien, die AWS für den Umzug von Anwendungen in die Cloud nennt: Retire, Retain, Rehost, Relocate, Repurchase, Replatform sowie Refactor oder Re-architect. Sie gehen auf die früheren fünf Rs von Gartner zurück. Kapitel 11
Dimensionstabelle: Eine Tabelle beschreibender Attribute, etwa Name, Küche und Stadt eines Restaurants, die zum Filtern und Gruppieren von Fakten dient. Kapitel 7
Disagree and Commit: Eine Norm, nach der Beteiligte ihren Widerspruch vor einer Entscheidung offen äußern und sich nach der Entscheidung voll für deren Umsetzung einsetzen. Kapitel 11
Disaster Recovery (DR): Die Pläne, Kopien und Verfahren, die einen Dienst und seine Daten nach einem großen Ausfall wiederherstellen, etwa nach dem Verlust eines ganzen Rechenzentrums oder einer ganzen Region. Kapitel 10
Diskontsatz: Der jährliche Zinssatz, mit dem künftige Geldbeträge in ihren heutigen Wert umgerechnet werden; er spiegelt Kapitalkosten und Risiko wider und wird meist von der Finanzabteilung festgelegt. Kapitel 11
Disposability: Die Eigenschaft von Prozessen, schnell zu starten, sauber herunterzufahren und jederzeit ohne Schaden beendet werden zu können, sodass sie frei ersetzt und skaliert werden können. Kapitel 10
Distributed SQL (NewSQL): Relationale Datenbanken wie Spanner und CockroachDB, die SQL und ACID-Transaktionen beibehalten und Daten zugleich über viele Knoten oder Regionen partitionieren und replizieren. Kapitel 7
Distributed Tracing: Das Aufzeichnen von Weg und Zeitverhalten einer Anfrage auf ihrem Weg durch viele Services, damit sich der langsame oder fehlschlagende Schritt finden lässt. Kapitel 9
DNS: Domain Name System: der Verzeichnisdienst des Internets, der Namen wie www.example.com in IP-Adressen umwandelt. Kapitel 0
Docker: Ein weit verbreiteter, 2013 veröffentlichter Werkzeugsatz zum Bauen von Container-Images und Ausführen von Containern. Sein Image-Format wurde zu einem offenen Standard. Kapitel 0
Docs as Code: Dokumentation mit denselben Werkzeugen und Abläufen erstellen wie Software: Textdateien in der Versionskontrolle, Code-Review, automatisierte Prüfungen und Veröffentlichung. Kapitel 4
Dokumentendatenbank: Eine NoSQL-Datenbank, die jeden Datensatz als in sich geschlossenes Dokument speichert, meist JSON-ähnlich, das verschachtelte Daten enthalten kann und kein festes gemeinsames Schema braucht. Kapitel 0
Domain Event: Eine Aufzeichnung über etwas Bedeutsames, das in der Geschäftsdomäne geschehen ist, in der Vergangenheitsform benannt, etwa OrderPlaced oder CourierAssigned. Kapitel 5
Domain Service: In einer servicebasierten Architektur ein separat deployter Service, der einen ganzen Geschäftsbereich wie Bestellungen oder Zahlungen abdeckt, von der API bis zum Datenzugriff. Kapitel 6
Domain-Driven Design (DDD): Ein 2003 von Eric Evans eingeführter Ansatz, der Software um ein gemeinsam mit Fachleuten entwickeltes Modell der Geschäftsdomäne herum baut und große Domänen in ausdrücklich abgegrenzte Modelle aufteilt. Kapitel 5
Domänenmodell: Ein kleines Diagramm oder eine Beschreibung der zentralen Geschäftskonzepte eines Systems, ihrer Attribute und ihrer Beziehungen, gemeinsam genutzt von Entwicklungsteam und Fachleuten der Domäne. Kapitel 4
DORA-Metriken: Die Kennzahlen der Softwareauslieferung aus dem DORA-Forschungsprogramm: Change Lead Time, Deployment-Häufigkeit, Wiederherstellungszeit nach fehlgeschlagenem Deployment, Change Fail Rate und Deployment Rework Rate. Kapitel 2
Drift: Eine allmähliche Veränderung der Eingaben eines KI-Systems, seiner Wissensquellen, der Welt oder des Modells selbst, durch die seine Ausgaben mit der Zeit ungenauer werden, ohne dass sich der Code ändert. Kapitel 12
DRY: Don’t repeat yourself: das Prinzip aus „The Pragmatic Programmer“, dass jedes Stück Wissen in einem System eine einzige maßgebliche Darstellung haben soll. Es geht um Wissen, nicht um gleich aussehenden Text. Kapitel 3
Dual Write: Die Aktualisierung zweier Systeme, etwa einer Datenbank und eines Message Brokers, in getrennten Operationen; ein Absturz dazwischen lässt die beiden inkonsistent zurück. Kapitel 6
Durchsatz: Die Arbeitsmenge, die ein System pro Zeiteinheit erledigt, etwa 1200 Anfragen pro Sekunde oder 40.000 Bestellungen pro Stunde. Kapitel 2
Dynamische Connascence: Connascence, die sich erst zeigt, wenn das Programm läuft, etwa die Abhängigkeit von Reihenfolge oder Zeitpunkt der Ausführung, von zusammenhängenden Werten oder davon, dass zwei Teile dieselbe Objektinstanz teilen. Kapitel 3
Dynamisches Diagramm: Ein ergänzendes C4-Diagramm, das zeigt, wie Elemente in einem Szenario zur Laufzeit zusammenarbeiten, meist als nummerierte Interaktionen. Kapitel 4

E

Edge Function: Ein kleines Stück Code, das ein CDN- oder Edge-Anbieter an Standorten nahe bei den Benutzern ausführt, um Anfragen zu bearbeiten oder zu verändern, bevor (oder statt dass) sie den Ursprungsserver erreichen. Kapitel 10
Efferente Kopplung (Ce): Die Zahl der Elemente außerhalb einer Komponente, von denen sie abhängt: ihre ausgehenden Abhängigkeiten. Eine hohe Ce bedeutet, dass sie den Änderungen vieler anderer ausgesetzt ist. Kapitel 3
Einer Anfrage folgen: Ein System erklären, indem man ein einzelnes konkretes Ereignis, etwa eine Bestellung, Schritt für Schritt durch jeden Teil verfolgt, den es berührt. Kapitel 4
Einseitige Architekturübersicht: Eine einzelne Seite mit Zweck, Qualitätszielen, Kontext, wichtigsten Bausteinen, zentralen Entscheidungen und Risiken eines Systems, als Einstieg in die ausführlichere Dokumentation. Kapitel 4
Elastizität: Die Fähigkeit, Ressourcen automatisch hinzuzufügen und zu entfernen, wenn die Last steigt und fällt, sodass die Kapazität dem Bedarf folgt und Sie nur für das zahlen, was Sie nutzen. Kapitel 2
Element: Ein Teil eines Systems, den ein Architekt oder eine Architektin als Einheit betrachtet, etwa ein Modul, ein Service, eine Datenbank, eine Queue oder ein Server. Kapitel 1
Embedding: Ein Zahlenvektor, der die Bedeutung eines Textes, eines Bildes oder eines Elements darstellt, so angeordnet, dass ähnliche Bedeutungen nahe beieinander liegen. Kapitel 12
Emergentes Design: Ein Ansatz, bei dem das Design schrittweise wächst, geprägt von den Anforderungen jeder neuen Funktionalität und kontinuierlichem Refactoring. Kapitel 1
Enabling Team: Ein Team aus Spezialisten, das anderen Teams für begrenzte Zeit hilft, eine fehlende Fähigkeit wie Testautomatisierung oder Observability aufzubauen, und dann weiterzieht, statt die Arbeit für sie zu erledigen. Kapitel 11
End-to-End-Test: Ein automatisierter Test, der das ganze System so bedient wie ein Benutzer, zum Beispiel durch Tippen durch eine App, um einen vollständigen Nutzungsablauf zu prüfen. Kapitel 0
Enterprise Service Bus (ESB): Middleware im Zentrum klassischer SOA, die Nachrichten zwischen Services weiterleitet, transformiert und vermittelt und oft auch Geschäftsprozesse ausführt. Kapitel 6
Entität: Ein Domänenobjekt, das durch eine Identität bestimmt ist, die über die Zeit bestehen bleibt, während sich seine Attribute ändern, etwa eine Bestellung oder ein Kunde. Kapitel 5
Entry Point (Python-Packaging): Metadaten in einem installierten Python-Paket, die ein Objekt, etwa eine Plug-in-Klasse, unter einer benannten Gruppe bekannt machen, damit anderer Code es zur Laufzeit finden kann. Kapitel 5
Entscheidungsprotokoll (Decision Log): Die geordnete Sammlung der ADRs eines Systems, meist mit einem Index, der Nummer, Titel, Status und Datum jedes Eintrags auflistet. Kapitel 4
Entscheidungsrechte: Eine ausdrückliche Festlegung, wer welche Entscheidungen treffen darf, wer konsultiert und wer informiert werden muss; wer sie vor einer Debatte klärt, verhindert die meisten Streitigkeiten über das Verfahren. Kapitel 11
Entscheidungstreiber: Eine Kraft oder ein Kriterium, etwa ein Qualitätsziel oder eine Randbedingung, die eine Architekturentscheidung erfüllen muss und anhand derer Optionen verglichen werden. Kapitel 4
Entwicklerportal: Eine Weboberfläche wie Backstage, die einen Softwarekatalog, Vorlagen, Dokumentation und Links zu Plattformdiensten an einem Ort bündelt. Kapitel 10
Entwurfsmuster: Eine wiederverwendbare Lösung für ein wiederkehrendes Problem im Maßstab weniger Klassen oder Objekte, etwa Strategy oder Observer; kleiner im Umfang als ein Architekturmuster. Kapitel 5
Envelope Encryption: Daten mit einem Datenschlüssel verschlüsseln und diesen Datenschlüssel dann mit einem im KMS gehaltenen Key-Encryption-Key verschlüsseln (umhüllen), sodass Massendaten nie zum KMS übertragen werden und Schlüssel günstig rotiert werden können. Kapitel 8
EPSS: Das Exploit Prediction Scoring System von FIRST, das die Wahrscheinlichkeit schätzt, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird. Kapitel 8
Ereignis (Event): Eine unveränderliche Aufzeichnung über etwas, das geschehen ist, in der Vergangenheitsform benannt, etwa OrderPlaced. Beliebig viele Empfänger können darauf reagieren. Kapitel 6
Ereignisgesteuerte Architektur: Ein Stil, bei dem Komponenten kommunizieren, indem sie Ereignisse über Geschehenes veröffentlichen und auf von anderen veröffentlichte Ereignisse reagieren, meist über einen Broker. Kapitel 6
Ereigniszeit (Event Time): Der Zeitpunkt, zu dem ein Ereignis tatsächlich stattfand, im Gegensatz zur Verarbeitungszeit, zu der ein System es wahrnimmt. Kapitel 7
Error Budget: Das Maß an Unzuverlässigkeit, das ein SLO zulässt: eins minus Zielwert, bezogen auf das Zeitfenster. Ein SLO von 99,9 % bei 1.000.000 Anfragen erlaubt 1000 fehlerhafte Anfragen. Kapitel 9
Error-Budget-Policy: Eine vereinbarte, schriftliche Festlegung, was ein Team tut, wenn sein Error Budget zu schnell verbraucht wird oder erschöpft ist, etwa riskante Releases einfrieren. Kapitel 9
Erweiterungspunkt: Ein benannter Steckplatz, den eine Host-Anwendung oder ein Plug-in deklariert, damit andere Plug-ins Verhalten dazu beitragen können, wie in der Eclipse-Plattform. Kapitel 5
Essenzielle Komplexität: Komplexität, die zum Problem selbst gehört, etwa die tatsächlichen Regeln des Steuer- oder Versicherungswesens, und die sich nicht beseitigen lässt, ohne zu ändern, was das System tut. Kapitel 3
ETag: Ein HTTP-Antwortheader mit einer Kennung für eine bestimmte Version einer Ressource, die ein Client in If-None-Match zurücksenden kann, um zu fragen, ob sie sich geändert hat. Kapitel 7
ETL: Extract, Transform, Load: eine Pipeline, die Daten aus Quellsystemen entnimmt, bereinigt und umformt und in einen Zielspeicher wie ein Data Warehouse lädt. Kapitel 5
EU AI Act (KI-Verordnung): Die Verordnung (EU) 2024/1689 (KI-Verordnung), das risikobasierte Gesetz der Europäischen Union über künstliche Intelligenz, 2026 geändert durch die Verordnung (EU) 2026/1744. Kapitel 12
Eval (Evaluierung): Ein wiederholbares Experiment, das eine feste Menge von Eingaben durch ein KI-System schickt und die Ausgaben bewertet, mit Zahlen, die sich zwischen Versionen vergleichen lassen. Kapitel 12
Event Interception: Ein Muster zur Ablösung von Altsystemen, das zustandsändernde Anfragen oder Ereignisse auf dem Weg in ein Altsystem abfängt und einige davon zusätzlich oder stattdessen an eine neue Komponente weiterleitet. Kapitel 11
Event Notification: Ein Ereignis, das nur eine Änderung signalisiert und oft nur eine Kennung enthält, sodass Empfänger, die Details brauchen, beim Herausgeber nachfragen müssen. Kapitel 6
Event Storming: Ein von Alberto Brandolini entwickeltes Workshop-Format, bei dem Fachleute der Domäne und Entwicklungsteams Domain Events auf einer Zeitachse anordnen, um einen Geschäftsprozess zu erkunden und Grenzen zu finden. Kapitel 5
Event-Carried State Transfer: Ereignisse, die genug Daten mitführen, damit Empfänger ihre eigene Kopie halten können und den Herausgeber nicht aufrufen müssen. Kapitel 6
Event-Sourcing: Jede Änderung an einer Entität als Ereignis speichern, sodass das Ereignisprotokoll die maßgebliche Quelle ist und der aktuelle Zustand durch erneutes Abspielen abgeleitet wird. Kapitel 6
Event-Stream: Die geordnete, nach Version nummerierte Folge von Ereignissen eines Aggregats, aus der der Zustand dieses Aggregats wiederhergestellt wird. Kapitel 7
Eventual Consistency: Eine Garantie, dass Kopien von Daten, die nicht mehr aktualisiert werden, nach einiger Zeit denselben Wert annehmen, während Leser zwischenzeitlich veraltete Werte sehen können. Kapitel 6
Evolutionäre Architektur: Eine Architektur, die gelenkte, schrittweise Veränderung über mehrere Dimensionen hinweg unterstützt, wobei Fitness Functions die Lenkung übernehmen (Ford, Parsons, Kua und Sadalage). Kapitel 11
Exit-Strategie: Ein dokumentierter und idealerweise geprobter Plan für den Ausstieg bei einem Anbieter oder Produkt, der Datenexport, Ersatzdienste, Verträge, Zeit und Kosten abdeckt. Kapitel 10
Expand and Contract: Einen Breaking Change in sicheren Schritten durchführen: die neue Struktur neben der alten hinzufügen, Leser, Schreiber und Daten migrieren und dann die alte Struktur entfernen. Auch Parallel Change genannt. Kapitel 7
Exponentielles Backoff: Zwischen aufeinanderfolgenden Wiederholungen immer länger warten, typischerweise mit Verdopplung der Wartezeit bis zu einer Obergrenze, damit ein überlasteter Service Zeit zur Erholung bekommt. Kapitel 9

F

Fachliche Partitionierung: Die Aufteilung der obersten Struktur eines Systems nach Geschäftsfähigkeit oder Subdomäne, etwa Bestellungen, Zahlungen und Lieferung. Kapitel 5
Failover: Das Umschalten der Arbeit von einer ausgefallenen Komponente auf einen funktionsfähigen Standby oder ein Replikat, automatisch oder von Hand. Kapitel 2
Faithfulness: In der RAG-Evaluierung das Maß, in dem jede Aussage einer Antwort durch die abgerufenen Textstellen gestützt wird; auch Groundedness genannt. Kapitel 12
Faktentabelle: Die zentrale Tabelle eines Sternschemas mit einer Zeile pro Geschäftsereignis in einer festgelegten Granularität, mit numerischen Kennzahlen und Schlüsseln zu den Dimensionen. Kapitel 7
Fallacies of Distributed Computing: Acht falsche Annahmen über Netzwerke, bei Sun Microsystems von L Peter Deutsch und Kollegen zusammengestellt, wobei James Gosling die achte ergänzte: zum Beispiel, dass das Netzwerk zuverlässig ist und die Latenz null beträgt. Kapitel 6
Fallback-Kaskade: Eine geordnete Liste von Alternativen (andere Regionen, Anbieter, Modelle, schließlich eine Antwort ohne KI), die der Reihe nach versucht werden, wenn das bevorzugte Modell versagt oder nicht verfügbar ist. Kapitel 12
Fan-out: Ein Muster, bei dem eine eingehende Anfrage mehrere parallele Anfragen an andere Services oder Server auslöst, deren Antworten dann zusammengeführt werden. Kapitel 2
Feature-Flag: Ein Konfigurationsschalter, der ein Verhalten zur Laufzeit ein- oder ausschaltet, ohne neuen Code zu deployen. Kapitel 1
Fehler (Error): Ein Teil des internen Zustands eines Systems, der falsch ist, weil eine Fehlerursache (Fault) aktiviert wurde, etwa ein beschädigter Datensatz. Ein Fehler kann zu einem Ausfall (Failure) führen, muss es aber nicht. Kapitel 2
Fehlertoleranz: Die Fähigkeit eines Systems, seinen Dienst weiter zu erbringen, obwohl einer seiner Teile ausgefallen ist, meist durch Redundanz. Kapitel 2
Fehlerursache (Fault): Die Ursache eines Problems, etwa ein Bug, eine defekte Festplatte oder eine Fehlkonfiguration. Eine Fehlerursache kann ruhen, bis etwas sie aktiviert. Kapitel 2
Feinentwurf: Entscheidungen über das Innere eines Teils eines Systems (seine Klassen, Funktionen, Algorithmen und lokalen Datenstrukturen), die sich ändern lassen, ohne den Rest zu beeinflussen. Kapitel 1
Filter: Ein in sich geschlossener Verarbeitungsschritt, der Eingaben liest und sie dann erzeugt, transformiert, prüft oder verbraucht, ohne zu wissen, welche Schritte vor oder nach ihm kommen. Kapitel 5
Fine-Tuning: Das Weitertrainieren eines bestehenden Modells mit einem kleineren, gezielten Datensatz, um ihm eine Aufgabe, ein Format, einen Ton oder ein Vokabular beizubringen. Kapitel 12
FinOps: Eine Praxis, bei der Engineering-, Finanz- und Fachteams gemeinsam Verantwortung für Cloud- und Technologieausgaben tragen und anhand zeitnaher Kostendaten Entscheidungen treffen, die den Geschäftswert maximieren. Kapitel 10
Fitness Function: Eine automatisierte Prüfung, die Ihnen sagt, ob ein System eine architektonische Eigenschaft noch besitzt, etwa ein Test, der fehlschlägt, wenn ein Modul von einem anderen abhängt, das es nicht verwenden darf. Kapitel 1
Flapping: Ein Autoscaler fügt wiederholt Kapazität hinzu und entfernt sie wieder, weil er auf kurzlebige Änderungen oder auf die Auswirkungen seiner eigenen Aktionen reagiert. Kapitel 9
Four Golden Signals: Latenz, Traffic, Fehler und Sättigung: die vier Messgrößen, die das Google-SRE-Buch für jedes benutzerseitige System zur Überwachung empfiehlt. Kapitel 9
Framework: Wiederverwendbarer Code, der die Gesamtstruktur einer Anwendung vorgibt und Ihren Code zu den richtigen Zeitpunkten aufruft, etwa Django oder Spring. Kapitel 0
Fremdschlüssel: Eine Spalte in einer Tabelle, die den Primärschlüssel einer Zeile in einer anderen Tabelle enthält und die beiden verknüpft. Die Datenbank kann Werte zurückweisen, die ins Leere zeigen. Kapitel 0
Funktion: Ein benanntes, wiederverwendbares Stück Code, das Eingaben (Parameter) entgegennimmt, eine Arbeit verrichtet und meist eine Ausgabe zurückgibt. Kapitel 0
Funktionale Anforderung: Eine Aussage darüber, was ein System tun muss: ein Verhalten, eine Berechnung oder eine Information, die es bereitstellen muss, etwa „ein Kunde kann eine Bestellung stornieren, bevor sie versandt wird“. Kapitel 2
FURPS+: Eine Qualitätsklassifikation, die bei Hewlett-Packard als FURPS (Functionality, Usability, Reliability, Performance und Supportability) entstand und später um „+“ für Randbedingungen wie Design, Implementierung, Schnittstellen und physische Grenzen erweitert wurde. Kapitel 2

G

Game Day: Eine geplante Übung, bei der ein Team absichtlich einen Ausfall herbeiführt oder simuliert und dessen Erkennung, die Reaktion darauf und die Wiederherstellung übt. Kapitel 9
Gate (Governance): Ein Kontrollpunkt, an dem die Arbeit anhält, bis jemand sie freigibt, etwa die Zustimmung eines Review Boards vor Build oder Release. Kapitel 11
Gateway API: Die Kubernetes-API zum Routing von externem und internem Traffic zu Services, seit 2023 allgemein verfügbar und der empfohlene Nachfolger von Ingress. Kapitel 10
Gauge: Eine Metrik, die einen aktuellen Wert festhält, der steigen oder fallen kann, etwa die Länge einer Queue, den belegten Speicher oder die Temperatur. Kapitel 9
Gemeinsame Datenhoheit (Joint Ownership): Eine Situation, in der mehrere Services dieselben Daten schreiben. Sie lässt sich auflösen, indem man die Tabelle aufteilt, eine kleine gemeinsame Datendomäne bildet, alle Schreibzugriffe an einen Eigentümer delegiert oder die Services zusammenlegt. Kapitel 7
Generische Subdomäne: Eine Subdomäne, deren Probleme viele Unternehmen teilen und für die es gute Lösungen gibt, etwa Zahlungen oder Identität; meist zugekauft oder schlank selbst gebaut. Kapitel 5
Geschäftliche Treiber: Die Geschäftsziele, Randbedingungen und der Kontext, die erklären, warum ein System existiert und was Erfolg bedeutet, etwa Wachstumsziele, Regulierung oder Verträge. In der ATAM werden sie zuerst vorgestellt, damit sich jedes Ergebnis auf sie zurückführen lässt. Kapitel 11
Geschlossene Schicht: Eine Schicht, die jede Anfrage durchlaufen muss: Die darüberliegende Schicht darf sie nicht überspringen, um direkt eine tiefere Schicht aufzurufen. Kapitel 5
Geschlossenes Lastmodell: Ein Lastmodell mit einer festen Zahl von Benutzern, von denen jeder erst dann eine neue Anfrage sendet, wenn die vorige beantwortet ist (plus Denkzeit), sodass die Last sinkt, wenn das System langsamer wird. Kapitel 9
Gesetz von Conway: Melvin Conways Beobachtung von 1968, dass Organisationen Systeme entwerfen, deren Struktur die Kommunikationsstruktur der Organisation selbst widerspiegelt. Kapitel 1
Getriebener (sekundärer) Adapter: Ein Adapter, der eine Schnittstelle implementiert, die die Anwendung aufruft, wenn sie etwas von außen braucht, etwa Daten speichern, eine Karte belasten oder eine Nachricht senden. Kapitel 5
Gewichtete Entscheidungsmatrix: Eine Tabelle, die jede Option anhand gewichteter Kriterien bewertet, damit die Begründung einer Wahl offenliegt und hinterfragt werden kann. Kapitel 1
Gewünschter Zustand (Desired State): Eine deklarative Beschreibung, wie ein System aussehen soll (zum Beispiel drei Kopien der Version 2.4), die eine Automatisierung mit dem tatsächlichen Zustand vergleicht und herzustellen versucht. Kapitel 10
Git: Das am weitesten verbreitete Versionskontrollsystem, 2005 von Linus Torvalds entwickelt. Jede Entwicklerin und jeder Entwickler hat eine vollständige Kopie der Projekthistorie. Kapitel 0
GitOps: Systeme betreiben, indem ihr deklarativer gewünschter Zustand in Git gehalten wird und Agenten ihn abrufen und das laufende System fortlaufend daran angleichen. Kapitel 10
Gleitendes Zeitfenster: Ein Messzeitraum, der sich kontinuierlich weiterbewegt, etwa die letzten 28 Tage, im Gegensatz zu einem Kalendermonat, der am Ersten neu beginnt. Kapitel 9
Globales Load Balancing: Die Verteilung von Benutzern auf Rechenzentren oder Regionen, meist durch DNS-Antworten, die sich je nach Standort und Zustand unterscheiden, oder durch Anycast-Routing. Kapitel 9
Golden Path (Paved Road): Ein meinungsstarker, unterstützter und dokumentierter Weg für eine häufige Aufgabe, etwa das Anlegen eines neuen Service, der der einfachste, aber nicht der einzige erlaubte Weg ist. Kapitel 10
Golden Set: Eine kuratierte, versionierte Sammlung von Testeingaben mit dem erwarteten Ergebnis, einer Referenzantwort oder einem Bewertungsschema für jede, die zur Bewertung eines KI-Systems dient. Kapitel 12
Goodharts Gesetz: Die Beobachtung, oft als „Wenn eine Kennzahl zum Ziel wird, hört sie auf, eine gute Kennzahl zu sein“ formuliert, dass Menschen die Zahl optimieren statt der Sache, die sie anzeigen sollte. Kapitel 3
Graceful Degradation: Weiterhin die wichtigsten Funktionen bereitstellen, wenn ein Teil eines Systems ausfällt, statt vollständig auszufallen, zum Beispiel ein Shop, der noch Bestellungen annimmt, während die Empfehlungen offline sind. Kapitel 2
Grad (der Connascence): Wie viele Elemente eine bestimmte Connascence teilen. Ein Wert, auf den sich zwei Funktionen geeinigt haben, ist weit leichter zu ändern als einer, auf den sich vierzig Services geeinigt haben. Kapitel 3
Granularität: Die Größe von Modulen oder Services im Verhältnis zum Gesamtsystem. Grobgranular heißt wenige große Teile, feingranular heißt viele kleine. Beides hat Kosten. Kapitel 3
Graphdatenbank: Eine Datenbank, die Elemente als Knoten und die Beziehungen zwischen ihnen als Kanten speichert, sodass das Verfolgen von Verbindungsketten schnell ist. Kapitel 0
GraphQL: Eine Abfragesprache und Laufzeitumgebung für APIs, 2015 von Facebook veröffentlicht, bei der der Client eine Abfrage sendet, die genau die gewünschten Felder aus einem typisierten Schema benennt, und eine Antwort derselben Form erhält. Kapitel 6
Grauer Kohlenstoff (Embodied Carbon): Die Treibhausgase, die bei Herstellung, Transport und Entsorgung von Hardware entstehen, im Gegensatz zu den Emissionen aus dem Strom, den sie im Betrieb verbraucht. Kapitel 11
Großes Sprachmodell (LLM): Ein sehr großer Transformer, der mit riesigen Textmengen darauf trainiert wird, das nächste Token vorherzusagen, und anschließend darauf abgestimmt wird, Anweisungen zu befolgen; er erzeugt Text, Code und strukturierte Daten. Kapitel 12
gRPC: Ein Framework für Remote Procedure Calls, 2015 von Google als Open Source veröffentlicht, das Protocol-Buffers-Nachrichten über HTTP/2 sendet und typisierten Client- und Server-Code erzeugt. Es unterstützt Streaming in eine oder beide Richtungen. Kapitel 6
Guard: Eine Bedingung in eckigen Klammern an einem Übergang oder Fluss, die wahr sein muss, damit er genommen wird, etwa [code matches]. Kapitel 4
Guardrail: Eine automatische Grenze oder Prüfung, die die Self-Service-Nutzung sicher hält (zum Beispiel eine Richtlinie, die öffentliche Storage-Buckets blockiert), ohne dass eine Person jede Anfrage genehmigen muss. Kapitel 10

H

Halluzination: Eine Modellausgabe, die flüssig und selbstsicher, aber falsch oder nicht durch ihre Quellen gedeckt ist, etwa ein erfundenes Zitat oder eine erfundene Richtlinie. Kapitel 12
Hardware: Die physischen Teile eines Computers, die man anfassen könnte: Prozessor, Arbeitsspeicher, Datenspeicher, Netzwerkkarte, Bildschirm und so weiter. Kapitel 0
Hardware-Sicherheitsmodul (HSM): Manipulationssichere Hardware, die Schlüssel in ihrem Inneren erzeugt und verwendet und sie nie im Klartext herausgibt; KMS-Dienste basieren meist auf HSMs. Kapitel 8
Hauptreihe (Main Sequence): Die Gerade A + I = 1 in einem Diagramm, das Abstraktheit gegen Instabilität aufträgt und auf der ausgewogene Komponenten liegen. Der Abstand von ihr ist D = |A + I - 1|. Kapitel 3
Health Check: Ein regelmäßiger Test, etwa eine HTTP-Anfrage an einen Status-Endpoint, anhand dessen ein Load Balancer oder Orchestrator entscheidet, ob eine Instanz Traffic erhalten oder neu gestartet werden soll. Kapitel 9
Heartbeat: Eine regelmäßige „Ich lebe noch“-Nachricht einer Komponente; bleiben die Nachrichten aus, nimmt ein Monitor an, dass die Komponente ausgefallen ist, und handelt. Kapitel 2
Hedged Request: Nach kurzer Verzögerung eine zweite Kopie einer langsamen Anfrage an ein anderes Replikat senden und die Antwort verwenden, die zuerst eintrifft, um die Tail-Latenz zu senken. Kapitel 9
Histogramm: Eine Metrik, die Beobachtungen wie Anfragedauern in Wertebereiche, sogenannte Buckets, einsortiert, sodass sich Perzentile schätzen und Histogramme vieler Server addieren lassen. Kapitel 9
HNSW: Hierarchical Navigable Small World Graphs (Malkov und Yashunin, 2016): ein weit verbreiteter Index für die approximative Nächste-Nachbarn-Suche über Vektoren. Kapitel 12
Hochrisiko-KI-System: Nach der KI-Verordnung ein KI-System, das Sicherheitsbauteil eines regulierten Produkts ist (Anhang I) oder in einem in Anhang III aufgeführten sensiblen Bereich wie Beschäftigung oder Kreditvergabe eingesetzt wird. Kapitel 12
Holistische Fitness Function: Eine Fitness Function, die mehrere Merkmale gemeinsam in einem geteilten Kontext prüft, etwa ein Lasttest, der die Latenz misst, während Sicherheit und Logging eingeschaltet sind. Kapitel 11
Horizontal Pod Autoscaler (HPA): Ein Kubernetes-Controller, der die Zahl der Pod-Replikate ändert, um eine Metrik, etwa die durchschnittliche CPU-Nutzung im Verhältnis zu den Requests, nahe an einem Zielwert zu halten. Kapitel 10
Horizontale Skalierung (Scale-out): Mehr Last bewältigen, indem weitere Maschinen hinzugefügt und die Arbeit auf sie verteilt wird, meist hinter einem Load Balancer. Kapitel 0
Hotspot: Ein Teil des Codes, der zugleich komplex ist und häufig geändert wird, gefunden durch die Kombination der Versionskontrollhistorie mit einem Komplexitätsmaß; ein naheliegender Ort, um Schulden zu tilgen. Kapitel 1
HTTP: Hypertext Transfer Protocol: die Anfrage-Antwort-Sprache des Web, in der ein Client eine Methode wie GET an eine URL sendet und ein Server mit einem Statuscode und Inhalt antwortet. Kapitel 0
HTTP-Statuscode: Eine dreistellige Zahl in jeder HTTP-Antwort, die angibt, wie die Anfrage verlaufen ist: 2xx Erfolg, 3xx Umleitung, 4xx ein Problem mit der Anfrage, 5xx ein Problem auf dem Server. Kapitel 0
Human in the Loop: Ein Design, bei dem eine Person die Ausgabe eines Modells prüft, freigibt oder korrigiert, bevor oder nachdem sie wirksam wird. Kapitel 12
Hybrid Cloud: Eine Kombination aus Private und Public Cloud (oder On-Premises-Systemen), die so verbunden ist, dass Daten und Anwendungen übergreifend arbeiten können. Kapitel 10
Hybride Suche: Ein Retrieval, das Ergebnisse der Schlüsselwortsuche (sparse) und der Embedding-Suche (dense) kombiniert, meist durch Zusammenführen ihrer Rankings, um die Stärken beider zu nutzen. Kapitel 12
Hypermedia Controls (HATEOAS): Links in einer API-Antwort, die dem Client sagen, welche Aktionen er als Nächstes ausführen kann, sodass der Client Links folgt, statt URLs selbst zusammenzusetzen. Stufe 3 des Richardson Maturity Model. Kapitel 6
Hypervisor: Software, die virtuelle Maschinen erzeugt und ausführt und dabei Prozessoren, Arbeitsspeicher und Geräte eines physischen Computers unter ihnen aufteilt, während sie sie voneinander isoliert hält. Kapitel 0
Hyrums Gesetz: Die nach Hyrum Wright benannte Beobachtung, dass bei genügend Nutzern einer API jedes beobachtbare Verhalten von irgendjemandem vorausgesetzt wird, gleichgültig, was der Vertrag verspricht. Kapitel 3

I

IaaS (Infrastructure as a Service): Ein Cloud-Modell, bei dem Sie virtuelle Maschinen, Speicher und Netzwerke mieten und das Betriebssystem und alles darüber selbst verwalten. Kapitel 0
Idempotent: Bezeichnet eine Operation, die dieselbe Wirkung hat, ob sie einmal oder mehrmals angewendet wird, sodass sie sicher wiederholt werden kann. Kapitel 5
Idempotenter Consumer: Ein Nachrichtenempfänger, der in derselben Transaktion wie ihre Auswirkungen festhält, welche Nachrichten er verarbeitet hat, sodass Duplikate nichts verändern. Kapitel 6
Idempotenz: Die Eigenschaft einer Operation, dieselbe Wirkung zu haben, ob sie einmal oder mehrmals ausgeführt wird, was Wiederholungen sicher macht. Wird meist mit einer eindeutigen Anfrage- oder Ereigniskennung erreicht, die sich der Empfänger merkt. Kapitel 6
Idempotenzschlüssel: Ein eindeutiger Wert, den ein Client mit einer nicht idempotenten Anfrage wie POST sendet, damit der Server eine Wiederholung derselben Operation erkennen und das ursprüngliche Ergebnis zurückgeben kann, statt die Arbeit doppelt zu erledigen. Kapitel 6
Immutable Infrastructure: Die Praxis, einen laufenden Server oder Container nie direkt zu verändern; jede Änderung erfolgt durch das Bauen eines neuen Images und das Ersetzen der alten Instanzen. Kapitel 10
Implizite Anforderung: Eine Qualität, die alle Stakeholder voraussetzen, aber niemand aufschreibt, etwa „Bestellungen gehen nie verloren“ oder „das System funktioniert auch bei einer Zeitumstellung weiter“. Kapitel 2
In-Memory Data Grid: Software, die Daten im Arbeitsspeicher vieler Maschinen als einen logischen Speicher hält, mit Partitionierung und Replikation, für sehr schnellen Zugriff. Hazelcast, Apache Ignite und Oracle Coherence sind Beispiele. Kapitel 6
Incident Commander: Die Person, die die Reaktion auf einen Incident koordiniert: Sie setzt Prioritäten, verteilt Rollen und trifft Entscheidungen, statt selbst Dinge zu reparieren. Kapitel 9
Incident Response: Die organisierte Behandlung eines Sicherheitsvorfalls: ihn erkennen und analysieren, eindämmen, die Ursache beseitigen, den Betrieb wiederherstellen und daraus lernen. Kapitel 8
Index: Eine zusätzliche Datenstruktur neben den Daten, mit der ein System Elemente anhand eines gewählten Felds findet, ohne alles zu durchsuchen, wie das Register hinten in einem Buch. Kapitel 0
Indirekte Prompt-Injection: Prompt-Injection über Inhalte, die das System liest, etwa eine Webseite, eine E-Mail, ein Dokument oder ein Tool-Ergebnis, statt über Eingaben des Benutzers. Kapitel 12
Inferenz: Die Nutzung eines trainierten Modells, um Ausgaben für neue Eingaben zu erzeugen. In Produktion ist sie ein Dienst mit Latenz, Durchsatz und Kosten pro Aufruf, anders als das Training, das ein schwerer Batch-Job ist. Kapitel 12
Information Hiding: Das Prinzip von David Parnas (1972), dass jedes Modul eine Designentscheidung verbergen soll, die schwierig ist oder sich wahrscheinlich ändert, damit sich die Entscheidung ändern kann, ohne andere Module zu beeinflussen. Kapitel 3
Infrastructure as Code (IaC): Die Definition von Servern, Netzwerken, Datenbanken und anderer Infrastruktur in versionskontrollierten Dateien, die Werkzeuge automatisch anwenden, statt sie von Hand zu konfigurieren. Kapitel 10
Instabilität (I): Martins Metrik I = Ce / (Ca + Ce), von 0 (maximal stabil: nur eingehende Abhängigkeiten) bis 1 (maximal instabil: nur ausgehende Abhängigkeiten). Kapitel 3
Integrationsdatenbank: Eine von mehreren Anwendungen gemeinsam genutzte Datenbank, über die sie sich integrieren, indem sie dieselben Tabellen lesen und schreiben. Martin Fowler (2004) rät davon ab, weil sie die Anwendungen eng koppelt. Kapitel 7
Integrationstest: Ein automatisierter Test, der prüft, ob mehrere Teile korrekt zusammenarbeiten, etwa Code mit einer echten Datenbank oder der API eines anderen Service. Kapitel 0
Interaktionsmodus: In Team Topologies eine von drei bewussten Arten der Zusammenarbeit zweier Teams: Collaboration, X-as-a-Service oder Facilitating. Die Modi sollen sich ändern, während Grenzen entdeckt werden und sich festigen. Kapitel 11
Interface Segregation Principle (ISP): Clients sollen nicht gezwungen sein, von Operationen abzuhängen, die sie nicht nutzen; mehrere kleine, clientspezifische Schnittstellen sind einer großen vorzuziehen. Kapitel 3
Internal Developer Platform (IDP): Die Gesamtheit der Self-Service-Werkzeuge, -Dienste, -Vorlagen und -Dokumentation, die das Plattformteam einer Organisation bereitstellt, damit Produktteams Software ohne Tickets bauen und betreiben können. Kapitel 10
Interoperabilität: Das Maß, in dem Systeme Informationen austauschen und das Ausgetauschte korrekt verwenden können, was Einigkeit über die Bedeutung ebenso wie über das Format erfordert. Kapitel 2
Interpreter: Ein Programm, das Code liest und seine Anweisungen fortlaufend ausführt, statt das ganze Programm vorab zu übersetzen. Kapitel 0
Invariante: Eine Bedingung, die für ein Modul oder Objekt zwischen Operationen immer wahr ist, etwa „ein Kontostand fällt nie unter sein Überziehungslimit“. Kapitel 3
Inverse Conway Maneuver: Teams und ihre Kommunikationswege bewusst so gestalten, dass sie der gewünschten Architektur entsprechen, damit das Gesetz von Conway für Sie statt gegen Sie arbeitet. Kapitel 3
Inversion of Control: Die Anordnung, bei der ein Framework und nicht Ihr eigener Code den Programmablauf steuert und Ihren Code bei Bedarf aufruft. Kapitel 0
IP-Adresse: Die numerische Adresse, die ein Gerät in einem Netzwerk identifiziert, damit Pakete an es zugestellt werden können, etwa 192.0.2.10 (IPv4) oder 2001:db8::1 (IPv6). Kapitel 0
ISO/IEC 25010: Das internationale Standardmodell für Produktqualität. Die Ausgabe von 2023 definiert neun Merkmale, von funktionaler Eignung bis Betriebssicherheit, jedes in Teilmerkmale gegliedert. Kapitel 2
ISO/IEC 42001: Die internationale Norm (2023), die Anforderungen an ein zertifizierbares KI-Managementsystem innerhalb einer Organisation festlegt. Kapitel 12
Isolationsebene: Eine Einstellung, die angibt, wie stark sich nebenläufige Transaktionen gegenseitig beeinflussen dürfen: Read Uncommitted, Read Committed, Repeatable Read, Snapshot oder Serializable. Die Namen bedeuten in verschiedenen Datenbanken Unterschiedliches. Kapitel 7
Isolationsschichten (Layers of Isolation): Die Eigenschaft, dass sich eine Änderung innerhalb einer Schicht nicht auf andere Schichten auswirkt, solange ihre Schnittstelle gleich bleibt; sie setzt geschlossene Schichten voraus. Kapitel 5

J

Jailbreak: Eine Eingabe, die ein Modell dazu bringen soll, die Sicherheitsrichtlinien zu brechen, die sein Anbieter ihm antrainiert hat. Kapitel 12
Jitter: Zufall, der Wartezeiten für Wiederholungen oder Zeitpläne beigemischt wird, damit nicht viele Clients im selben Moment handeln und synchronisierte Lastspitzen erzeugen. Kapitel 9
Join: Eine SQL-Operation, die Zeilen aus zwei oder mehr Tabellen über zusammengehörige Spalten verknüpft, etwa Bestellungen mit den Kunden, die sie aufgegeben haben. Kapitel 0
JSON (JavaScript Object Notation): Ein Textformat für strukturierte Daten aus Objekten (Name-Wert-Paare in geschweiften Klammern), Arrays (Listen in eckigen Klammern), Strings, Zahlen, true, false und null. Standardisiert in RFC 8259. Kapitel 0
JSON Web Token (JWT): Ein kompaktes, signiertes (und optional verschlüsseltes) Token mit Claims wie Aussteller, Subjekt, Zielgruppe und Ablaufzeit, definiert in RFC 7519; weit verbreitet für Access Tokens und ID-Tokens. Kapitel 8
Just-enough-Dokumentation: Dokumentation, deren Umfang sich danach richtet, was ihre Leser tatsächlich brauchen, sodass mehr zu schreiben und zu pflegen mehr kosten würde, als es einbringt. Kapitel 4

K

Kaltstart (Cold Start): Die zusätzliche Verzögerung, wenn eine Serverless-Plattform eine neue Funktionsinstanz erzeugen und initialisieren muss, bevor sie eine Anfrage bearbeitet, von einigen zehn Millisekunden bis zu mehreren Sekunden. Kapitel 6
Kanban: Eine Methode, Arbeit als kontinuierlichen Fluss auf einem visuellen Board zu steuern und dabei zu begrenzen, wie viele Aufgaben gleichzeitig in Bearbeitung sein dürfen. Kapitel 0
Kanonisches Datenmodell: Eine einzige unternehmensweite Darstellung jeder Geschäftsentität, in die und aus der alle Nachrichten übersetzt werden. Passt selten gut zu allen Teilen eines Unternehmens. Kapitel 6
Kapazitätsplanung: Die Prognose des künftigen Bedarfs, die Messung, wie viel jede Infrastruktureinheit bewältigen kann, und die rechtzeitige Bereitstellung ausreichender Kapazität mit Reserve, bevor sie gebraucht wird. Kapitel 9
Kapazitätsreserve (Headroom): Freie Kapazität, die bewusst über der erwarteten Spitzenlast vorgehalten wird, um Lastspitzen, Ausfälle und die Zeit bis zur Bereitstellung weiterer Kapazität abzufangen. Kapitel 9
Kapitalwert (NPV): Die Summe der künftigen Zahlungsströme einer Investition, jeweils auf den heutigen Wert abgezinst, abzüglich der Anfangskosten; ein positiver Kapitalwert bedeutet, dass die Investition mehr als den Diskontsatz erwirtschaftet. Kapitel 11
Kapselung: Die internen Daten und Details eines Objekts oder Moduls privat halten, sodass anderer Code es nur über die Operationen nutzen kann, die es anbieten will. Kapitel 0
Kardinalität: Die Zahl der unterschiedlichen Werte, die ein Feld annehmen kann; bei Metriken die Zahl der unterschiedlichen Label-Kombinationen, von denen jede zu einer eigenen zu speichernden Zeitreihe wird. Kapitel 9
Kaskadierender Ausfall: Ein Ausfall, der sich ausbreitet: Eine langsame oder ausgefallene Komponente lässt ihre Aufrufer warten und deren eigene Ressourcen erschöpfen, sodass auch sie ausfallen, und so weiter die Kette hinauf. Kapitel 6
Kausale Konsistenz: Ein Konsistenzmodell, bei dem kausal zusammenhängende Operationen (eine könnte die andere beeinflusst haben) von allen in derselben Reihenfolge gesehen werden; nicht zusammenhängende nebenläufige Operationen können in unterschiedlicher Reihenfolge erscheinen. Kapitel 6
Kernsystem: In einer Microkernel-Architektur der minimale Teil der Anwendung, den jede Installation braucht: der Hauptablauf, gemeinsame Dienste und die Stellen, an denen Plug-ins andocken. Kapitel 5
Key Management Service (KMS): Ein Managed Service, der kryptografische Schlüssel erzeugt, speichert, rotiert und ihre Verwendung kontrolliert und die Operationen selbst ausführt, sodass Anwendungen die Master-Schlüssel nie zu sehen bekommen. Kapitel 8
Key-Value-Store: Eine Datenbank, die Werte unter eindeutigen Schlüsseln speichert und nur über den Schlüssel abruft, wie ein sehr großes, sehr schnelles Dictionary. Kapitel 0
KI-Modell mit allgemeinem Verwendungszweck: Nach der KI-Verordnung ein KI-Modell, etwa ein großes Sprachmodell, das ein breites Spektrum von Aufgaben erfüllen und in viele nachgelagerte Systeme integriert werden kann. Kapitel 12
KISS: Keep it simple: eine Faustregel für den Entwurf aus der Ingenieurspraxis der 1960er-Jahre, nach der unnötige Komplexität zu vermeiden ist, weil sie ein System schwerer verständlich, schwerer zu betreiben und schwerer zu reparieren macht. Kapitel 3
Klasse und Objekt: Eine Klasse ist eine Vorlage, die Daten mit den Funktionen (Methoden) bündelt, die auf ihnen arbeiten; ein Objekt ist eine aus dieser Vorlage erzeugte Instanz, etwa das Konto eines bestimmten Kunden. Kapitel 0
Kognitive Last: Der geistige Aufwand, den eine Person oder ein Team aufbringen muss, um ein System zu verstehen und darin zu arbeiten; Team Topologies nutzt ihn, um den Zuschnitt der Teamverantwortlichkeiten zu bemessen. Kapitel 10
Kognitive Last des Teams: Die gesamte Menge an Wissen und geistiger Anstrengung, die ein Team braucht, um die Teile eines Systems, für die es zuständig ist, zu bauen, zu betreiben und zu ändern. Übersteigt sie die Kapazität des Teams, sinken Qualität und Geschwindigkeit. Kapitel 3
Kognitive Verzerrung: Ein systematischer Denkfehler, etwa der Ankereffekt oder der Sunk-Cost-Effekt, der dazu führt, dass Menschen Optionen unfair beurteilen. Kapitel 1
Kohäsion: Wie eng die Inhalte eines Teils eines Systems zusammengehören. Hohe Kohäsion bedeutet, dass ein Modul eine klare Aufgabe erfüllt. Kapitel 0
Kommunikationspfade: Die möglichen Eins-zu-eins-Verbindungen zwischen den Mitgliedern einer Gruppe. Eine Gruppe von n Personen hat n(n-1)/2 davon, die Zahl wächst also ungefähr mit dem Quadrat der Gruppengröße. Kapitel 3
Kompensierende Transaktion: Eine neue Transaktion, die die Wirkung einer früheren, bereits festgeschriebenen Transaktion inhaltlich aufhebt, etwa die Stornierung einer Kartenautorisierung. Anders als bei einem Rollback kann das Original bereits gesehen worden sein. Kapitel 6
Komponente: Eine Einheit, die zur Laufzeit des Systems existiert, etwa ein Service, ein Prozess oder eine Datenbank, und über Konnektoren mit anderen Komponenten interagiert. Kapitel 1
Komponente (C4): Im C4-Modell eine Gruppe zusammengehöriger Funktionalität hinter einer klaren Schnittstelle, die innerhalb eines Containers läuft und mit ihm deployt wird. Kapitel 4
Komponenten-und-Konnektoren-Sicht: Eine Sicht auf das, was zur Laufzeit existiert, etwa Services, Clients, Datenbanken und Queues, und auf die Konnektoren (Aufrufe, Nachrichten, gemeinsame Daten) zwischen ihnen. Kapitel 4
Konfigurationsdrift: Abweichungen, die sich zwischen der im Code beabsichtigten Konfiguration und der realen Infrastruktur aufbauen, meist durch manuelle Änderungen oder unvollständige Updates. Kapitel 10
Konfigurationsmanagement: Werkzeuge wie Ansible, Chef und Puppet, die bestehende, langlebige Server in eine beschriebene Konfiguration bringen, indem sie Pakete installieren und Dateien auf ihnen bearbeiten. Kapitel 10
Konkretes Szenario: Ein Szenario, das für ein bestimmtes System formuliert ist, mit konkreten Akteuren, Ereignissen, Bedingungen und Zahlen, bereit für Entwurf und Test. Kapitel 2
Konnektor: Der Laufzeitmechanismus, über den Komponenten interagieren: ein HTTP-Aufruf, eine Message Queue, eine gemeinsame Datenbank, ein Event-Stream oder ein Funktionsaufruf. Kapitel 1
Konsens: Eine Entscheidungsregel, bei der die Gruppe so lange weitermacht, bis alle dem Vorschlag aktiv zustimmen oder ihn zumindest unterstützen; inklusiv, aber langsam und in großen Gruppen anfällig für Blockaden. Kapitel 11
Konsententscheidung: Eine Entscheidungsregel, bei der ein Vorschlag angenommen wird, sofern niemand einen begründeten Einwand erhebt, dass er Schaden anrichten oder die Gruppe zurückwerfen würde; sie fragt, ob die Beteiligten mit einem Vorschlag leben können, nicht, ob sie ihn bevorzugen. Kapitel 11
Konsistentes Hashing: Ein Verfahren, Schlüssel auf einem Hash-Ring Knoten zuzuordnen, sodass beim Hinzufügen oder Entfernen eines Knotens nur etwa 1/N der Schlüssel verschoben werden (Karger und Kollegen, 1997). Kapitel 7
Konsistenzmodell: Der Vertrag, den ein Datenspeicher darüber anbietet, welche Werte Lesezugriffe angesichts der erfolgten Schreibzugriffe zurückgeben dürfen, und damit, auf welche veralteten oder umgeordneten Ergebnisse Clients vorbereitet sein müssen. Kapitel 6
Kontextfenster: Die maximale Zahl von Tokens, die ein Modell bei einem Aufruf berücksichtigen kann, einschließlich Anweisungen, Verlauf, bereitgestellter Dokumente und seiner eigenen Antwort. Kapitel 12
Kontextweitergabe (Context Propagation): Die Weitergabe von Trace-IDs (und anderem Anfragekontext) von einem Service zum nächsten mit jedem Aufruf oder jeder Nachricht, zum Beispiel im W3C-Header traceparent. Kapitel 9
Kontinuierliche Fitness Function: Eine Fitness Function, die ständig gegen das Live-System läuft, etwa SLO-Monitoring oder synthetische Transaktionen, statt durch einen Build oder ein Ereignis ausgelöst zu werden. Kapitel 11
Kopplung: Wie stark ein Teil eines Systems von den Details eines anderen abhängt. Lose Kopplung bedeutet, dass eine Änderung an einem Teil selten Änderungen an anderer Stelle erzwingt. Kapitel 0
Korrespondenz: Eine festgehaltene Beziehung zwischen Elementen einer Architekturbeschreibung, zum Beispiel zwischen einem Container in einer Sicht und dem Server, auf dem er in einer anderen läuft. Kapitel 4
Kubernetes: Der am weitesten verbreitete Open-Source-Container-Orchestrator, entstanden bei Google, 2014 angekündigt und 2015 als Version 1.0 veröffentlicht; er sorgt dafür, dass der tatsächliche Zustand eines Clusters einem deklarierten gewünschten Zustand entspricht. Kapitel 10

L

Lakehouse: Eine Architektur, die Data-Warehouse-Funktionen wie Transaktionen, Schemas und schnelle Abfragen für Daten bereitstellt, die in offenen Dateiformaten auf Object Storage liegen. Kapitel 7
Last Responsible Moment: Der Zeitpunkt, ab dem ein weiteres Aufschieben einer Entscheidung eine wichtige Option zunichtemachen würde; wer dann entscheidet, nutzt die meisten Informationen, ohne Schaden zu verursachen. Kapitel 1
Last Write Wins: Eine Regel zur Konfliktauflösung, die den Schreibvorgang mit dem jüngsten Zeitstempel behält und die anderen verwirft. Einfach, aber gleichzeitige Änderungen gehen stillschweigend verloren, und Uhrabweichungen können den falschen Gewinner bestimmen. Kapitel 6
Lasttest: Ein Performance-Test, der die erwartete (oder prognostizierte Spitzen-)Last über einen Zeitraum anlegt, um zu prüfen, ob die Ziele für Latenz und Fehlerrate eingehalten werden. Kapitel 9
Latenz: Die Verzögerung, bis Daten ankommen oder eine Antwort zurückkommt, meist in Millisekunden gemessen. Entfernung, Netzwerk-Hops und langsame Verarbeitung tragen alle dazu bei. Kapitel 0
Latenzbudget: Der Anteil eines End-to-End-Ziels für die Antwortzeit, der jedem Schritt oder Service auf dem Weg einer Anfrage zugeteilt wird, sodass jedes Team weiß, welche Grenze es einhalten muss. Kapitel 11
Laterale Bewegung (Lateral Movement): Das Vordringen eines Angreifers vom ersten kompromittierten Rechner oder Konto zu weiteren Systemen innerhalb desselben Netzwerks oder derselben Organisation. Kapitel 8
Layer-4-Load-Balancer: Ein Load Balancer, der auf der Transportebene (TCP oder UDP) arbeitet und Verbindungen oder Pakete weiterleitet, ohne die darin enthaltene HTTP-Anfrage zu lesen. Kapitel 9
Layer-7-Load-Balancer: Ein Load Balancer, der das Anwendungsprotokoll versteht, meist HTTP, und daher jede Anfrage nach Pfad, Header oder Cookie routen, TLS terminieren und Anfragen wiederholen kann. Kapitel 9
LCOM (mangelnde Kohäsion der Methoden): Eine Familie von Metriken auf Klassenebene, die die Kohäsion danach schätzen, wie die Methoden einer Klasse deren Felder gemeinsam nutzen; ein hoher Wert deutet darauf hin, dass die Klasse mehrere voneinander unabhängige Verantwortlichkeiten trägt. Kapitel 3
Leader-Follower-Replikation: Ein Replikationsverfahren, bei dem ein Knoten (der Leader oder Primary) alle Schreibvorgänge annimmt und seine Änderungen an Follower (Replikate) streamt, die Lesezugriffe bedienen können. Kapitel 7
Leaderless Replication: Ein Verfahren im Stil von Dynamo, bei dem Clients direkt auf mehrere Replikate schreiben und von mehreren lesen und statt eines einzelnen Leaders Quoren verwenden. Kapitel 7
Leaky Abstraction: Eine Abstraktion, deren verborgene Details sich dennoch auf ihre Nutzer auswirken, zum Beispiel ein entfernter Aufruf, der wie ein lokaler aussieht, bis das Netzwerk langsam ist oder ausfällt. Von Joel Spolsky 2002 so benannt. Kapitel 3
Leaky Bucket: Ein Algorithmus für Rate Limiting oder Traffic Shaping, bei dem Anfragen in einen Eimer gelangen und ihn mit konstanter Rate verlassen; ist der Eimer voll, werden neue Anfragen abgewiesen. Kapitel 9
Least Connections: Ein Load-Balancing-Algorithmus, der jede neue Anfrage an die Instanz schickt, die gerade die wenigsten Anfragen oder Verbindungen in Bearbeitung hat. Kapitel 9
Least Frequently Used (LFU): Eine Verdrängungsstrategie, die bei vollem Cache das Element entfernt, das am seltensten gelesen wurde. Kapitel 7
Least Privilege: Das Prinzip, dass jeder Benutzer, jedes Programm und jeder Service nur die Berechtigungen erhält, die für die jeweilige Aufgabe nötig sind, und nur so lange wie nötig, sodass ein Fehler oder eine Kompromittierung nur begrenzten Schaden anrichtet. Kapitel 8
Least Recently Used (LRU): Eine Verdrängungsstrategie, die bei vollem Cache das Element entfernt, das am längsten nicht mehr gelesen wurde. Kapitel 7
Lebende Dokumentation: Dokumentation, die sich mit dem beschriebenen System weiterentwickelt, oft weil sie aus dem System selbst erzeugt oder gegen es geprüft wird. Kapitel 4
Lebenslinie: In einem Sequenzdiagramm die gestrichelte senkrechte Linie unter einem Teilnehmer, entlang der seine Nachrichten und Aktivierungen in zeitlicher Reihenfolge dargestellt werden. Kapitel 4
Lethal Trifecta: Simon Willisons Bezeichnung (2025) für die gefährliche Kombination aus Zugriff auf private Daten, dem Kontakt mit nicht vertrauenswürdigen Inhalten und der Fähigkeit, nach außen zu kommunizieren. Kapitel 12
Linearisierbarkeit: Das stärkste Konsistenzmodell für einzelne Objekte: Jede Operation scheint zu einem einzigen Zeitpunkt zwischen ihrem Beginn und ihrem Ende stattzufinden, in einer Reihenfolge, die alle Clients teilen und die die reale Zeit respektiert, als gäbe es nur eine Kopie. Kapitel 6
Linux: Ein freier Open-Source-Betriebssystemkern, der zusammen mit weiterer Software als Betriebssystem auf den meisten Servern, Cloud-Maschinen und Containern sowie auf Android-Smartphones läuft. Kapitel 0
Liskov Substitution Principle (LSP): Alles, was sich als Subtyp ausgibt, muss überall dort verwendbar sein, wo sein Supertyp erwartet wird, ohne dass der Aufrufer einen Unterschied im Verhalten bemerkt. Benannt nach Barbara Liskov. Kapitel 3
Littles Gesetz: Die Regel L = λ × W: Die durchschnittliche Anzahl der Elemente in einem stabilen System ist gleich der durchschnittlichen Ankunftsrate multipliziert mit der durchschnittlichen Verweildauer jedes Elements darin. Kapitel 2
Liveness Probe: Ein Health Check, der prüft, ob ein Prozess unrettbar hängt; schlägt er fehl, startet der Orchestrator die Instanz neu. Kapitel 9
LLM-as-a-Judge: Der Einsatz eines Sprachmodells, um Ausgaben anhand eines Bewertungsschemas zu bewerten oder zu vergleichen; skalierbar, aber anfällig für Verzerrungen, die anhand menschlicher Urteile gemessen werden müssen. Kapitel 12
LLMOps: Praktiken für Entwicklung, Release, Monitoring und Verbesserung von Anwendungen auf Basis großer Sprachmodelle, einschließlich der Versionierung von Prompts und Modellen, des Tracings von Aufrufen und der Evaluierung in der Pipeline. Kapitel 12
Load Balancer: Eine Komponente, die eingehende Anfragen entgegennimmt und auf mehrere Server verteilt, wobei sie fehlerhafte Server überspringt. Kapitel 0
Load Shedding: Das bewusste, frühe und kostengünstige Abweisen einiger Anfragen, wenn ein System überlastet ist, damit die angenommenen Anfragen weiterhin rechtzeitig erfolgreich sind. Kapitel 9
Lock-in: Die Kosten und Schwierigkeiten, von einem Anbieter, Produkt, einer Plattform oder Technologie wegzuwechseln, sobald ein System davon abhängt. Kapitel 10
Lockfile: Eine von einem Paketmanager erzeugte Datei, die die genauen Versionen und meist auch die Hashes aller aufgelösten Abhängigkeiten festhält, sodass jede Installation dieselben Pakete verwendet. Kapitel 8
Logisches Modul: Eine Verantwortungseinheit im Entwurf, etwa Bestellungen oder Zahlungen, unabhängig davon, wie ihr Code paketiert oder deployt wird. Kapitel 3
Lokalität (der Connascence): Wie nah die connascenten Elemente beieinanderliegen: innerhalb einer Funktion, eines Moduls, einer Komponente oder über ein Netzwerk hinweg. Starke Connascence ist nur dann tragbar, wenn sie lokal ist. Kapitel 3
Lost Update: Eine Anomalie, bei der zwei Transaktionen einen Wert lesen, jede einen neuen berechnet und zurückschreibt, sodass eine Änderung die andere stillschweigend überschreibt. Kapitel 7
Lösungsarchitektur: Die Architektur einer Lösung für ein einzelnes Geschäftsproblem, die oft mehrere Anwendungen, Anbieter und Teams umfasst, etwa ein neuer Online-Schadensmeldeprozess für einen Versicherer. Kapitel 1

M

Macht-Interesse-Matrix: Eine Vier-Felder-Matrix, die Stakeholder nach ihrer Macht über ein Projekt und ihrem Interesse daran einordnet, um zu planen, wie eng jede Gruppe eingebunden wird. Kapitel 1
MADR: Markdown Architectural Decision Records: eine weit verbreitete ADR-Vorlage mit Entscheidungstreibern, betrachteten Optionen, dem Ergebnis, den Konsequenzen und der Bestätigung. Kapitel 4
Magischer Wert: Eine literale Zahl oder Zeichenkette, deren Bedeutung im Code nicht angegeben ist, etwa ein Status 3 für „versandt“. Sie erzeugt Connascence of Meaning zwischen allem, was sie verwendet. Kapitel 3
Managed Database: Ein von einem Cloud-Anbieter betriebener Datenbankdienst, der Installation, Patches, Backups und Failover übernimmt, während der Kunde Schema, Abfragen und Zugriffe verwaltet. Kapitel 0
Managed Service: Ein Cloud-Dienst, etwa eine Datenbank, eine Queue oder ein Speicherdienst, den der Anbieter installiert, betreibt, patcht und skaliert, sodass Kunden ihn nutzen, ohne ihn selbst zu betreiben. Kapitel 0
Maschinelles Lernen: Eine Funktion aus Beispielen statt aus handgeschriebenen Regeln aufbauen: Ein Modell wird an Daten angepasst und dann genutzt, um Vorhersagen für neue Eingaben zu treffen. Kapitel 12
Maschinencode: Als Zahlen codierte Anweisungen, die eine bestimmte CPU-Familie direkt ausführen kann. Maschinencode für eine Familie (zum Beispiel x86-64) läuft nicht auf einer anderen (zum Beispiel Arm). Kapitel 0
Mean Time Between Failures (MTBF): Die durchschnittliche Zeit von einem Ausfall einer reparierbaren Komponente oder eines Systems bis zum nächsten. Kapitel 2
Mean Time to Failure (MTTF): Die durchschnittliche Zeit, die eine Komponente fehlerfrei läuft, bevor sie ausfällt. Kapitel 2
Mean Time to Repair (MTTR): Die durchschnittliche Zeit von einem Ausfall bis zur Wiederherstellung des Service. Manche Organisationen lesen das R als „recover“ oder „restore“; geben Sie immer an, welcher Start- und Endpunkt gemessen wird. Kapitel 2
Mediator-Topologie: Eine ereignisgesteuerte Topologie, in der ein Mediator ein auslösendes Ereignis empfängt und den Workflow steuert, indem er in festgelegter Reihenfolge Commands an Prozessoren sendet. Kapitel 6
Menschliche Aufsicht: Vorkehrungen, mit denen Menschen die Entscheidungen eines KI-Systems überwachen, freigeben, übersteuern oder stoppen können. Kapitel 12
Message Queue: Software, die Nachrichten von Sendern speichert, bis die Empfänger bereit sind, sie zu verarbeiten, sodass beide nicht gleichzeitig laufen oder gleich schnell sein müssen. Kapitel 0
Microkernel-Architektur: Ein Architekturstil, auch Plug-in-Architektur genannt, bei dem ein kleines Kernsystem den allgemeinen Ablauf bereitstellt und unabhängige Plug-ins über veröffentlichte Verträge Verhalten hinzufügen oder ändern. Kapitel 5
Microservice Premium: Martin Fowlers Begriff (2015) für die zusätzlichen Kosten und Risiken, die Microservices mit sich bringen und die sich erst lohnen, wenn System und Organisation komplex genug sind. Kapitel 5
Microservices: Ein Stil, bei dem eine Anwendung aus kleinen Services aufgebaut wird, die jeweils in einem eigenen Prozess laufen, um eine fachliche Fähigkeit herum geschnitten, unabhängig deploybar sind und über leichtgewichtige Mechanismen kommunizieren. Kapitel 6
Migration: Ein versioniertes Skript, das ein Datenbankschema oder dessen Daten von einer Version auf die nächste bringt, in der Versionskontrolle liegt und automatisch angewendet wird. Kapitel 7
Mikrosegmentierung: Die Aufteilung eines Netzwerks in sehr kleine Zonen bis hinunter zu einzelnen Workloads, sodass jede nur Datenverkehr von den Aufrufern annimmt, die sie benötigt. Kapitel 8
Mirroring Hypothesis: Die wissenschaftliche Fassung des Gesetzes von Conway: Die technischen Abhängigkeiten in einem Produkt entsprechen tendenziell den Kommunikations- und Organisationsbeziehungen zwischen den Menschen, die es bauen. Kapitel 3
Model Card: Ein kurzes, zusammen mit einem Modell veröffentlichtes Dokument, das den vorgesehenen Einsatz, Evaluierungsergebnisse über verschiedene Gruppen hinweg, Trainingsdaten, Grenzen und ethische Überlegungen beschreibt (Mitchell et al., 2019). Kapitel 12
Model Context Protocol (MCP): Ein offenes Protokoll, im November 2024 von Anthropic eingeführt und inzwischen unter dem Dach der Linux Foundation verwaltet, zur Anbindung von KI-Anwendungen an Server, die Tools, Daten und Prompts bereitstellen. Kapitel 12
Modell der geteilten Verantwortung (Shared Responsibility): Die Aufteilung der Sicherheits- und Betriebspflichten zwischen einem Cloud-Anbieter, der die Cloud selbst absichert, und dem Kunden, der seine Daten, Identitäten und Konfiguration in der Cloud absichert. Kapitel 10
Modellart (Model Kind): In ISO/IEC/IEEE 42010 die Konventionen für eine Modellart, etwa ein UML-Sequenzdiagramm oder ein C4-Containerdiagramm. Kapitel 4
Modellierungswerkzeug: Ein Werkzeug, das Elemente und Beziehungen in einem Modell speichert und Diagramme als Sichten darauf erzeugt, wobei alle Sichten konsistent bleiben. Kapitel 4
Modellkaskade: Ein Entwurf, der eine Anfrage zuerst an ein günstigeres Modell schickt und nur dann an ein leistungsfähigeres eskaliert, wenn eine Prüfung ergibt, dass die erste Antwort nicht gut genug ist. Kapitel 12
Modul: Eine Codeeinheit, oft eine einzelne Datei, die zusammengehörige Funktionen und Daten unter einem Namen bündelt und festlegt, was sie anderem Code zur Verfügung stellt. Ein Paket ist eine Gruppe von Modulen. Kapitel 0
Modul-API: Der kleine, bewusst öffentliche Teil eines Moduls, den andere Module nutzen dürfen; alles andere ist intern und darf sich frei ändern. Kapitel 5
Modularer Monolith: Eine einzige deploybare Anwendung, deren Code entlang fachlicher Grenzen in Module aufgeteilt ist, jedes mit einer expliziten öffentlichen Schnittstelle und eigenen Daten. Kapitel 5
Modularität: Der Grad, in dem ein System in Teile gegliedert ist, die sich weitgehend für sich allein verstehen, ändern und testen lassen. Ein Teilmerkmal der Wartbarkeit in ISO/IEC 25010. Kapitel 3
Modulsicht: Eine Sicht auf die Implementierungseinheiten (Pakete, Bibliotheken, Schichten) und ihre Abhängigkeiten, wie sie zur Entwicklungszeit bestehen. Kapitel 4
Monitoring: Das Erfassen und Beobachten vordefinierter Messwerte und Prüfungen, damit bekannte Arten von Ausfällen erkannt und gemeldet werden. Kapitel 9
Monolith: Ein System, das als eine einzige Einheit gebaut und deployt wird, selbst wenn sein Code intern in sauber getrennte Module aufgeteilt ist. Kapitel 1
MonolithFirst: Martin Fowlers Rat von 2015, ein neues System als gut modularisierten Monolithen zu beginnen und Services erst später herauszulösen, wenn die Grenzen verstanden und Services nötig sind. Kapitel 5
Monolithische Architektur: Eine Architektur, bei der die gesamte Anwendung als eine einzige Einheit gebaut und deployt wird, unabhängig von ihrer inneren Struktur. Kapitel 5
Monotonic Reads: Eine Garantie, dass die späteren Lesevorgänge eines Clients, sobald er einen Wert gesehen hat, nie einen älteren zurückgeben, sodass Daten nie in der Zeit zurückzuspringen scheinen. Kapitel 6
Multi-Cloud: Die Nutzung von Diensten zweier oder mehrerer Public-Cloud-Anbieter, etwa wegen besonderer Dienste, Übernahmen, Verhandlungsmacht oder regulatorisch geforderter Exit-Pläne. Kapitel 10
Multi-Faktor-Authentifizierung (MFA): Authentifizierung, die zwei oder mehr verschiedene Arten von Faktoren verlangt: etwas, das Sie wissen, etwas, das Sie haben, und etwas, das Sie sind. Kapitel 8
Multi-Leader-Replikation: Ein Verfahren, bei dem mehrere Knoten Schreibvorgänge annehmen und untereinander replizieren, was eine Möglichkeit erfordert, widersprüchliche Schreibvorgänge zu erkennen und aufzulösen. Kapitel 7
Multi-Version Concurrency Control (MVCC): Eine Technik, bei der Schreibvorgänge neue Zeilenversionen anlegen, statt zu überschreiben, sodass Leser einen konsistenten Snapshot sehen, ohne Schreiber zu blockieren. Kapitel 7
Multi-Window-, Multi-Burn-Rate-Alert: Ein SLO-Alert, der nur auslöst, wenn die Burn Rate sowohl über ein langes als auch über ein kurzes Zeitfenster über einem Schwellenwert liegt, und so schnelle Erkennung mit schnellem Zurücksetzen und wenigen Fehlalarmen verbindet. Kapitel 9
Multiplizität: In einem UML-Klassendiagramm, wie viele Objekte an jedem Ende einer Assoziation beteiligt sein dürfen, etwa 1, 0..1, 0..* oder 1..*. Kapitel 4
Mutual TLS (mTLS): TLS, bei dem beide Seiten Zertifikate vorlegen und prüfen, sodass ein Service weiß, welcher Service ihn aufruft, und der Aufrufer zugleich den Server kennt. Kapitel 8

N

N+1-Abfrageproblem: Ein Performance-Fehler, bei dem Code eine Abfrage stellt, um eine Liste von N Elementen zu holen, und dann pro Element eine weitere Abfrage, was N+1 Roundtrips ergibt, wo ein oder zwei genügen würden. Kapitel 6
Nachbedingung: Eine Bedingung, die eine Operation bei ihrem Abschluss garantiert, sofern ihre Vorbedingung erfüllt war. Kapitel 3
Nachricht (Message): Beliebige Daten, die ein Programm über einen Kanal an ein anderes sendet; sie können ein Ereignis, einen Command, eine Abfrage oder eine Antwort enthalten. Kapitel 6
Netzwerkpartition: Ein Netzwerkfehler, der ein System in Gruppen von Knoten aufspaltet, die nicht miteinander kommunizieren können, obwohl jede Gruppe weiterlaufen und für manche Clients erreichbar sein kann. Kapitel 6
Nicht-Risiko (Non-Risk): Eine Entscheidung, die für ein bestimmtes Szenario als tragfähig beurteilt und zusammen mit den Annahmen festgehalten wird, auf denen sie beruht, damit sie erneut geprüft werden kann, wenn sich diese Annahmen ändern. Kapitel 11
Nichtfunktionale Anforderung (NFR): Eine weit verbreitete, aber unscharfe Bezeichnung für Qualitätsanforderungen und Randbedingungen. Viele Architekten vermeiden sie, weil diese Anforderungen Funktionen näher bestimmen, statt losgelöst von ihnen zu stehen. Kapitel 2
NIST AI RMF: Das freiwillige AI Risk Management Framework des US-amerikanischen National Institute of Standards and Technology (Version 1.0, 2023), aufgebaut auf den Funktionen Govern, Map, Measure und Manage. Kapitel 12
NoSQL: Ein Sammelbegriff für Datenbanken, die nicht das relationale Tabellenmodell verwenden, etwa Dokumenten-, Key-Value-, Wide-Column- und Graphdatenbanken. Kapitel 0
Nutzungsqualität: Die Qualität, die ein Produkt Menschen in einem bestimmten Nutzungskontext bietet (ob es nützlich, risikofrei und akzeptabel ist). Seit 2023 hat sie eine eigene Norm, ISO/IEC 25019. Kapitel 2

O

O-Notation (Big-O): Eine Art zu beschreiben, wie der Aufwand eines Algorithmus mit der Datenmenge wächst, zum Beispiel O(n) für lineares Wachstum oder O(1) für konstante Zeit. Kapitel 0
OAuth 2.0: Das Framework für delegierte Autorisierung aus RFC 6749, bei dem ein Autorisierungsserver Access Tokens ausstellt, mit denen ein Client im Namen eines Ressourceneigentümers einen Ressourcenserver aufrufen kann, ohne dessen Passwort zu sehen. Kapitel 8
Observability: Wie gut Menschen anhand der Daten, die ein laufendes System ausgibt (Logs, Metriken, Traces), verstehen können, was darin vorgeht, auch bei Problemen, mit denen niemand gerechnet hat. Kapitel 2
Offene Schicht: Eine Schicht, die die darüberliegende Schicht umgehen darf, typischerweise eine Schicht gemeinsamer Services, die nur manche Anfragen benötigen. Kapitel 5
Offenes Lastmodell: Ein Lastmodell, bei dem neue Anfragen mit einer festgelegten Rate eintreffen, unabhängig davon, wie schnell frühere beantwortet werden, so wie Kunden, die eine Website aufrufen. Kapitel 9
Offline-Evaluierung: Die Evaluierung einer Version eines KI-Systems anhand fester Datensätze, bevor sie die Nutzer erreicht. Kapitel 12
Offset: Die fortlaufende Position eines Ereignisses innerhalb einer Partition; Consumer speichern den erreichten Offset, damit sie nach einem Neustart dort weitermachen können. Kapitel 6
OLAP: Online Analytical Processing: Workloads aus großen Abfragen, die viele Datensätze durchsuchen und aggregieren, etwa Umsatz nach Region und Monat. Kapitel 7
OLTP: Online Transaction Processing: Workloads aus vielen kleinen Lese- und Schreibzugriffen auf einzelne Datensätze, etwa das Aufgeben von Bestellungen oder das Verbuchen von Zahlungen. Kapitel 7
Online-Evaluierung: Die Evaluierung eines KI-Systems mit Live-Traffic, zum Beispiel über Shadow Deployments, Canaries oder A/B-Tests. Kapitel 12
Open Container Initiative (OCI): Ein 2015 gegründetes Projekt der Linux Foundation, das offene Standards für Container-Image-Formate, Laufzeitumgebungen und Registries pflegt, sodass Werkzeuge verschiedener Anbieter zusammenarbeiten. Kapitel 10
Open Host Service: Ein Context-Map-Muster, bei dem ein Upstream-Kontext allen seinen Konsumenten ein einziges klar definiertes, dokumentiertes Protokoll oder API anbietet. Kapitel 5
Open Table Format: Eine Spezifikation wie Apache Iceberg, Delta Lake oder Apache Hudi, die Datendateien und Metadaten so organisiert, dass viele Engines sie als Tabellen mit Transaktionen und Time Travel behandeln können. Kapitel 7
Open-Closed Principle (OCP): Ein Modul sollte offen für Erweiterung, aber geschlossen für Änderung sein: Neues Verhalten sollte durch Hinzufügen von Code entstehen, etwa durch eine neue Implementierung einer Schnittstelle, nicht durch Bearbeiten funktionierenden Codes. Erstmals 1988 von Bertrand Meyer formuliert. Kapitel 3
Open-Weight-Modell: Ein Modell, dessen trainierte Gewichte veröffentlicht werden, damit andere es ausführen können, unter einer Lizenz, die großzügig oder restriktiv sein kann. Offene Gewichte allein machen ein Modell noch nicht zu Open Source. Kapitel 12
OpenAPI: Ein standardisiertes, maschinenlesbares Format zur Beschreibung von HTTP-APIs (Pfade, Operationen, Parameter, Schemas), früher die Swagger-Spezifikation. Es dient als Grundlage für Dokumentation, Codegenerierung und Tests. Kapitel 6
OpenID Connect (OIDC): Eine Identitätsschicht auf OAuth 2.0, die ein ID-Token hinzufügt, ein signiertes JWT, das dem Client mitteilt, wer der Benutzer ist und wie und wann er sich authentifiziert hat. Kapitel 8
OpenTelemetry: Ein herstellerneutrales Open-Source-Projekt der CNCF, das APIs, SDKs, ein Protokoll (OTLP) und einen Collector bereitstellt, um Traces, Metriken und Logs zu erzeugen und zu exportieren. Kapitel 9
OpenTofu: Ein Open-Source-Fork von Terraform, entstanden 2023, nachdem HashiCorp Terraform unter die Business Source Licence gestellt hatte; unter dem Dach der Linux Foundation und ein CNCF-Projekt. Kapitel 10
Optimistische Nebenläufigkeitskontrolle: Konflikte erkennen statt verhindern: Ein Schreibvorgang gelingt nur, wenn eine Versionsnummer oder ein Zeitstempel seit dem Lesen der Daten unverändert ist; andernfalls versucht der Schreibende es erneut. Kapitel 7
Orchestrierung: Die Koordination eines mehrstufigen Prozesses durch eine Komponente, die jedem Beteiligten sagt, was zu tun ist, und entscheidet, was als Nächstes geschieht. Kapitel 6
Overfitting: Wenn ein Modell Eigenheiten seiner Trainingsdaten statt des allgemeinen Musters lernt, sodass es bei bekannten Beispielen gut und bei neuen schlecht abschneidet. Kapitel 12

P

PaaS (Platform as a Service): Ein Cloud-Modell, bei dem Sie Ihren Anwendungscode oder Container liefern und der Anbieter die darunterliegende Plattform betreibt, patcht und skaliert. Kapitel 0
PACELC: Daniel Abadis Erweiterung des CAP-Theorems: Bei einer Partition (P) ist zwischen Verfügbarkeit (A) und Konsistenz (C) abzuwägen; andernfalls (E, „Else“), im Normalbetrieb, zwischen Latenz (L) und Konsistenz (C). Kapitel 6
Paket (Netzwerk): Ein kleines Datenstück, das mit angehängten Adressinformationen über ein Netzwerk gesendet wird. Große Nachrichten werden in viele Pakete aufgeteilt und am anderen Ende wieder zusammengesetzt. Kapitel 0
Paketmanager: Ein Werkzeug wie pip (Python) oder npm (JavaScript), das Bibliotheken und die Bibliotheken, von denen sie abhängen, in den Versionen herunterlädt, die ein Projekt vorgibt. Kapitel 0
Parallelbetrieb: Der parallele Betrieb der alten und der neuen Implementierung mit denselben Eingaben und der Vergleich ihrer Ergebnisse, während die alte maßgeblich bleibt, um vor der Umstellung nachzuweisen, dass die neue gleichwertig ist. Kapitel 11
Partition (eines Topics): In Kafka und ähnlichen Logs ein geordneter Teil eines Topics, an den nur angehängt wird. Events mit demselben Schlüssel landen in derselben Partition; die Reihenfolge ist nur innerhalb einer Partition garantiert. Kapitel 6
Partitionierung (Sharding): Die Aufteilung eines Datenbestands, sodass jede Maschine nur einen Teil davon hält, ausgewählt über einen Partitionsschlüssel, um Schreibvorgänge und Speicher über eine Maschine hinaus zu skalieren. Kapitel 7
Passkey: Ein FIDO2/WebAuthn-Credential: ein für eine Website erzeugtes Schlüsselpaar, dessen privater Schlüssel auf dem Gerät oder im Passwortmanager des Benutzers bleibt, was die Anmeldung phishingresistent macht und kein gemeinsames Geheimnis auf dem Server hinterlässt. Kapitel 8
Passwort-Hashing: Das Speichern eines Passworts als Ausgabe einer absichtlich langsamen, gesalzenen Funktion wie Argon2id, scrypt oder bcrypt, sodass eine gestohlene Datenbank nicht mit geringem Aufwand in Passwörter zurückverwandelt werden kann. Kapitel 8
Paved Road (Golden Path): Ein unterstützter, gut dokumentierter Standardweg, Software zu bauen und zu betreiben, etwa eine Service-Vorlage mit bereits eingerichtetem Logging, Sicherheit und Deployment, den Teams verlassen dürfen, wenn sie gute Gründe haben. Kapitel 11
Pay-as-you-go: Ein Preismodell, bei dem Ihnen Ressourcen nur berechnet werden, solange Sie sie nutzen, zum Beispiel pro Sekunde Serverzeit oder pro gespeichertem Gigabyte. Kapitel 0
Performance-Budget: Eine vereinbarte Obergrenze für eine Performance-Kennzahl, etwa das Seitengewicht oder die p99-Latenz pro Service-Aufruf, die eine Änderung nicht überschreiten darf, idealerweise automatisch geprüft. Kapitel 9
Perimetersicherheit: Das traditionelle Modell, das ein vertrauenswürdiges internes Netzwerk mit Firewalls und VPNs schützt und alles, was bereits innen ist, als freundlich behandelt; manchmal auch Burg-und-Graben-Modell genannt. Kapitel 8
Personenbezogene Daten: Nach der DSGVO alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (einen lebenden Menschen) beziehen, etwa ein Name, eine Kennnummer, Standortdaten oder eine Online-Kennung. Kapitel 8
Perspektive: Im Ansatz von Rozanski und Woods ein Qualitätsanliegen wie Sicherheit oder Performance, das quer über alle Sichten angewendet wird, statt als eigene Sicht gezeichnet zu werden. Kapitel 4
Perzentil (p95, p99): Der Wert, unter dem ein bestimmter Anteil der Messungen liegt. Ein p99 von 400 ms bedeutet, dass 99 % der Anfragen 400 ms oder weniger und 1 % länger gedauert haben. Kapitel 2
Pessimistisches Sperren: Konflikte verhindern, indem Zeilen beim Lesen gesperrt werden (zum Beispiel mit SELECT ... FOR UPDATE), sodass andere Transaktionen warten, bis die Sperre aufgehoben ist. Kapitel 7
Physisches Modul: Eine Einheit, die gebaut, versioniert oder deployt wird, etwa eine JAR-Datei, ein Python-Paket, ein Container-Image oder ein Service. Ein logischer Entwurf lässt sich auf viele Arten in physische Module verpacken. Kapitel 3
Pilot Light: Eine Disaster-Recovery-Strategie, die Daten repliziert und die Kerninfrastruktur in einer zweiten Region bereithält, die Anwendungsserver aber erst im Katastrophenfall startet und skaliert. Kapitel 10
Pipe: Ein Einwegkanal, der Daten von einem Filter zum nächsten transportiert, meist mit einem Puffer dazwischen. Kapitel 5
Pipes and Filters: Ein Stil, bei dem Daten durch eine Kette unabhängiger Verarbeitungsschritte (Filter) fließen, die über Einwegkanäle (Pipes) verbunden sind. Kapitel 5
PKCE: Proof Key for Code Exchange (RFC 7636): Der Client sendet zu Beginn des Authorization-Code-Flows einen Hash eines Einmalgeheimnisses und beim Einlösen des Codes das Geheimnis selbst, sodass ein gestohlener Code nutzlos ist. Kapitel 8
Platform Engineering: Die Disziplin, interne Plattformen zu bauen und zu betreiben, über die Produktteams Software per Self-Service bereitstellen, deployen und betreiben können. Kapitel 10
Plattformteam: Ein Team, das interne Dienste, Werkzeuge und Infrastruktur als Self-Service-Produkt bereitstellt, damit Stream-aligned Teams liefern können, ohne tiefes Fachwissen über die zugrunde liegende Technologie zu benötigen. Kapitel 11
Plug-in: Ein separat gebautes Modul, das einer Host-Anwendung über einen vom Host veröffentlichten Vertrag Verhalten hinzufügt, ohne dass der Code des Hosts geändert wird. Kapitel 5
Plug-in-Registry: Der Teil eines Kernsystems, der festhält, welche Plug-ins verfügbar sind, mit ihren Namen, Versionen und Verträgen, damit der Kern sie findet, ohne sie im Code zu benennen. Kapitel 5
Plug-in-Vertrag: Die veröffentlichte Schnittstelle zwischen einem Kernsystem und seinen Plug-ins: die Operationen, Datentypen, das Fehlerverhalten und die Version, auf die sich beide Seiten einigen. Kapitel 5
Pod: Die kleinste deploybare Einheit in Kubernetes: ein oder mehrere Container, die gemeinsam auf einem Knoten eingeplant werden und sich eine Netzwerkadresse und Speicher-Volumes teilen. Kapitel 10
Policy as Code: Das Formulieren von Regeln für Infrastruktur und Deployments (kein öffentlicher Speicher, Verschlüsselung vorgeschrieben, nur genehmigte Regionen) als Code, den Werkzeuge vor oder während Änderungen automatisch prüfen. Kapitel 10
Policy Decision Point (PDP): Die Komponente, die Zugriffsrichtlinien auswertet und mit „erlauben“ oder „verweigern“ antwortet; ein Policy Enforcement Point (PEP) fragt sie an und setzt die Antwort dann durch. Kapitel 8
Policy Enforcement Point (PEP): Die Komponente im Datenpfad, etwa ein Proxy, Gateway oder Sidecar, die jede Anfrage entsprechend einer Richtlinienentscheidung zulässt oder blockiert. Kapitel 8
Polyglotte Persistenz: Der Einsatz verschiedener Datenbankarten für verschiedene Daten innerhalb eines Systems, ausgewählt danach, wie jeder Datenbestand genutzt wird, um den Preis, mehr Technologien betreiben zu müssen. Kapitel 7
Port: Eine Zahl von 0 bis 65535, die angibt, welches Programm auf einem Gerät Netzwerkverkehr empfangen soll, etwa 443 für HTTPS. Kapitel 0
Ports and Adapters (hexagonale Architektur): Alistair Cockburns Stil, bei dem eine Anwendung nur über Ports (Schnittstellen, die ihr gehören) mit der Außenwelt kommuniziert und Adapter zwischen jedem Port und einer bestimmten Technologie übersetzen. Kapitel 5
Post-Incident-Review: Ein strukturiertes Meeting mit schriftlichem Bericht nach einem Incident, das rekonstruiert, was geschehen ist, warum es den Beteiligten damals sinnvoll erschien und was sich ändern wird; auch Postmortem genannt. Kapitel 9
Power of Two Random Choices: Ein Load-Balancing-Verfahren, das zwei Instanzen zufällig auswählt und die Anfrage an die weniger ausgelastete schickt; Mitzenmacher zeigte, dass es fast so gut verteilt, wie wenn man jede Instanz prüfen würde. Kapitel 9
Pre-Mortem: Gary Kleins Technik (2007), bei der sich ein Team vorstellt, sein Projekt sei bereits gescheitert, und jede Person aufschreibt, warum; so kommen Risiken zum Vorschein, die sonst ungern angesprochen werden. Kapitel 11
Precision und Recall: Precision ist der Anteil der von einem Modell markierten Elemente, die tatsächlich positiv sind; Recall ist der Anteil der tatsächlich positiven Elemente, die das Modell erkennt. Wer den einen Wert erhöht, senkt meist den anderen. Kapitel 12
Primärschlüssel: Eine Spalte oder Gruppe von Spalten, deren Wert jede Zeile einer Tabelle eindeutig identifiziert, etwa customer_id. Kapitel 0
Private Cloud: Cloud-Infrastruktur, die einer einzigen Organisation vorbehalten ist und Self-Service-Bereitstellung über APIs bietet; sie kann On-Premises stehen oder von einem Drittanbieter gehostet werden. Kapitel 10
Probe (Liveness, Readiness, Startup): Eine regelmäßige Prüfung eines Containers durch Kubernetes: Liveness entscheidet, ob er neu gestartet wird, Readiness, ob er Datenverkehr erhält, Startup, ob er fertig gestartet ist. Kapitel 10
Problem Details (RFC 9457): Ein Standard-JSON-Format für Fehler von HTTP-APIs mit den Membern type, title, status, detail und instance, ausgeliefert als application/problem+json. RFC 9457 (2023) hat RFC 7807 abgelöst. Kapitel 6
Produktion: Die Live-Umgebung, auf die echte Nutzer und echte Daten angewiesen sind. Kapitel 0
Programm: Eine Liste präziser Anweisungen, die ein Computer befolgt, um eine Aufgabe zu erledigen. Ein laufendes Programm heißt Prozess. Kapitel 0
Progressive Delivery: Das Ausliefern einer Änderung an schrittweise größere Nutzergruppen mit automatischen Prüfungen bei jedem Schritt, sodass eine fehlerhafte Änderung möglichst wenige Nutzer erreicht, bevor sie gestoppt wird. Kapitel 10
Projektion: Code, der auf Änderungen oder Ereignisse lauscht und ein Lesemodell aktuell hält; auch Bezeichnung für das so erzeugte Lesemodell. Kapitel 7
Prompt: Alles, was in einem Aufruf an ein Sprachmodell gesendet wird: Systemanweisungen, Gesprächsverlauf, abgerufene Dokumente, Tool-Definitionen und die Nachricht des Benutzers. Kapitel 12
Prompt-Caching: Die Wiederverwendung des berechneten Zustands eines Modells für ein identisches, kürzlich gesehenes Prompt-Präfix, was Kosten und Latenz des wiederholten Teils senkt. Kapitel 12
Prompt-Injection: Ein Angriff, bei dem von einem Benutzer gelieferter oder in vom Modell gelesenen Inhalten versteckter Text Anweisungen enthält, die das vorgesehene Verhalten der Anwendung aushebeln oder unterwandern. Kapitel 12
Proof of Concept: Ein kleines, zeitlich begrenztes Stück funktionierenden Codes, das gebaut wird, um zu prüfen, ob eine Idee, Technologie oder Entwurfsentscheidung funktioniert, bevor man sich darauf festlegt. Kapitel 1
Protocol Buffers: Ein sprachneutrales, kompaktes Binärformat für strukturierte Daten, definiert in .proto-Dateien, in denen jedes Feld eine dauerhafte Nummer hat. Wird von gRPC und vielen Messaging-Systemen verwendet. Kapitel 6
Provenienz (Provenance): Überprüfbare Informationen darüber, woher ein Artefakt stammt: welche Build-Plattform es gebaut hat, aus welcher Quellcode-Revision, mit welchen Eingaben und Parametern. Kapitel 8
Prozess: Eine laufende Instanz eines Programms mit eigenem privatem Speicher und eigenem Anteil an CPU-Zeit, vom Betriebssystem erzeugt und verwaltet. Kapitel 0
Prozessinternes Ereignis (In-Process Event): Eine Nachricht, die innerhalb einer laufenden Anwendung veröffentlicht wird, damit andere Module auf ein Geschehen reagieren können, ohne dass der Herausgeber weiß, wer zuhört. Kapitel 5
Pseudonymisierung: Die Verarbeitung personenbezogener Daten in einer Weise, dass sie ohne Hinzuziehung gesondert aufbewahrter zusätzlicher Informationen nicht mehr einer Person zugeordnet werden können; nach der DSGVO sind pseudonymisierte Daten weiterhin personenbezogene Daten. Kapitel 8
Psychologische Sicherheit: Die im Team geteilte Überzeugung, dass es sicher ist, zwischenmenschliche Risiken einzugehen, etwa Fehler zuzugeben oder einer erfahrenen Kollegin oder einem Vorgesetzten zu widersprechen; von Amy Edmondson seit 1999 erforscht. Kapitel 11
Public-Key-Infrastruktur (PKI): Die Zertifizierungsstellen, Zertifikate, Trust Stores, Richtlinien und Sperrmechanismen, die es Beteiligten gemeinsam ermöglichen, die öffentlichen Schlüssel der jeweils anderen zu überprüfen. Kapitel 8
Publish-Subscribe: Ein Messaging-Muster, bei dem ein Publisher eine Nachricht an ein Topic sendet und jeder Subscriber seine eigene Kopie erhält, ohne dass der Publisher weiß, wer sie sind. Kapitel 6
Published Language: Ein dokumentiertes, gemeinsames Format für den Informationsaustausch zwischen Kontexten, etwa ein versioniertes Event-Schema, oft über einen Open Host Service angeboten. Kapitel 5
Pull Request: Eine Anfrage, einen Branch in die Hauptlinie zu mergen, auf einer Plattform wie GitHub, wo Kollegen die Änderung reviewen und automatische Prüfungen laufen, bevor sie angenommen wird. Kapitel 0

Q

Qualitätsmerkmal: Eine messbare Eigenschaft eines Systems, die angibt, wie gut es seine Aufgabe erfüllt, etwa Performance, Verfügbarkeit, Sicherheit oder Änderbarkeit. Kapitel 2 behandelt sie ausführlich. Kapitel 1
Qualitätsmodell: Eine strukturierte Liste von Qualitätsmerkmalen und ihren Teilmerkmalen, die als gemeinsames Vokabular und als Checkliste beim Festlegen oder Bewerten von Qualität dient. Kapitel 2
Qualitätsszenario: Eine kurze, testbare Formulierung einer Qualitätsanforderung aus sechs Teilen: Quelle des Stimulus, Stimulus, Artefakt, Umgebung, Antwort und Antwortmaß. Kapitel 2
Quality Attribute Workshop (QAW): Eine moderierte Methode des SEI, bei der Stakeholder zu Beginn eines Projekts Qualitätsszenarien sammeln, zusammenführen, darüber abstimmen und sie verfeinern. Kapitel 2
Quellcode: Der für Menschen lesbare Text eines Programms, geschrieben in einer Programmiersprache wie Python oder Java, der anschließend kompiliert oder interpretiert wird, damit ein Computer ihn ausführen kann. Kapitel 0
Querschnittliches Konzept: Eine Regel oder Lösung, die für viele Teile eines Systems gilt, etwa Sicherheit, Fehlerbehandlung, Logging oder Persistenz. Kapitel 4
Querschnittsanliegen (Cross-Cutting Concern): Ein Anliegen, das viele Teile eines Systems zugleich betrifft, etwa Logging, Sicherheit, Fehlerbehandlung oder Persistenz, und daher meist einmal für das ganze System entschieden wird. Kapitel 1
Queue (Punkt-zu-Punkt-Kanal): Ein Messaging-Kanal, bei dem jede Nachricht an genau einen der lesenden Consumer zugestellt wird, sodass sich mehrere Instanzen die Arbeit teilen können. Kapitel 6
Quorum (R + W > N): In einem Speicher mit N Replikaten wartet ein Schreibvorgang auf W Bestätigungen und ein Lesevorgang auf R Antworten; ist R + W > N, überschneidet sich jede Lesemenge mit jeder Schreibmenge in mindestens einem Replikat. Kapitel 6

R

Rabatt für Nutzungszusagen: Ein niedrigerer Preis im Gegenzug für die Zusage einer bestimmten Nutzung oder Ausgabenhöhe für ein oder drei Jahre, etwa Reserved Instances, Savings Plans oder Committed Use Discounts. Kapitel 10
RAM (Arbeitsspeicher): Random-Access Memory: schneller, flüchtiger Speicher, der die gerade verwendeten Programme und Daten enthält. Sein Inhalt geht verloren, wenn der Strom ausfällt oder das Programm endet. Kapitel 0
Randbedingung: Eine Designentscheidung, die bereits für Sie getroffen wurde und keinen oder nur sehr wenig Spielraum lässt, etwa eine vorgeschriebene Programmiersprache, eine Vorschrift, eine feste Frist oder ein Budget. Kapitel 2
Rate Limit: Eine Obergrenze dafür, wie viele Anfragen ein Client in einem Zeitraum stellen darf, etwa 100 pro Minute. Anfragen darüber werden abgewiesen, typischerweise mit dem HTTP-Status 429. Kapitel 0
Rate Limiting: Die Begrenzung, wie viele Anfragen ein Client, ein Schlüssel oder ein Mandant in einem Zeitraum stellen darf, um Kapazität zu schützen und fair zu verteilen; überzählige Anfragen werden meist mit HTTP 429 beantwortet. Kapitel 9
Re-Ranking: Eine zweite Retrieval-Stufe, in der ein genaueres, aber langsameres Modell die besten Kandidaten der ersten Stufe neu bewertet und die besten wenigen behält. Kapitel 12
ReAct: Reasoning and Acting (Yao und Kollegen, 2022): ein Muster, bei dem ein Modell Denkschritte mit Aktionen abwechselt und jede Beobachtung nutzt, um den nächsten Schritt festzulegen. Kapitel 12
Read Replica: Eine Kopie einer Datenbank, die die Änderungen des Primärsystems empfängt und Leseabfragen bedient, was den Primärknoten entlastet, um den Preis leicht veralteter Daten. Kapitel 5
Read-your-Writes: Eine Garantie, dass ein Client, nachdem er einen Wert geschrieben hat, bei seinen eigenen späteren Lesevorgängen diesen Schreibvorgang oder einen neueren Stand sieht, auch wenn andere Clients das noch nicht tun. Kapitel 6
Readiness Probe: Ein Health Check, der prüft, ob eine Instanz gerade Datenverkehr bedienen kann; schlägt er fehl, wird die Instanz aus dem Load Balancer genommen, ohne neu gestartet zu werden. Kapitel 9
Reasoning-Modell: Ein Sprachmodell, das darauf trainiert ist, vor der Antwort Zwischenschritte des Denkens als Tokens zu erzeugen, und dabei zusätzliche Kosten und Latenz gegen bessere Ergebnisse bei schwierigen mehrstufigen Aufgaben abwägt. Kapitel 12
Rechenzentrum: Ein Gebäude, das dafür ausgelegt ist, viele Server mit zuverlässiger Stromversorgung, Kühlung, physischer Sicherheit und Netzwerkanbindung zu beherbergen. Kapitel 0
Rechtsgrundlage: Eine der sechs Bedingungen in Artikel 6 DSGVO (Einwilligung, Vertrag, rechtliche Verpflichtung, lebenswichtige Interessen, öffentliche Aufgabe, berechtigte Interessen), auf der die Verarbeitung personenbezogener Daten beruhen muss. Kapitel 8
Reconciliation Loop: Der endlose Zyklus eines Controllers, der den tatsächlichen Zustand beobachtet, ihn mit dem gewünschten Zustand vergleicht und handelt, um den Unterschied zu beseitigen. Kapitel 10
Recovery Point Objective (RPO): Die größte Datenmenge, gemessen als Zeitspanne, deren Verlust das Unternehmen in einem Katastrophenfall hinnehmen kann, zum Beispiel die Änderungen der letzten 15 Minuten. Kapitel 2
Recovery Time Objective (RTO): Die längste Zeit, die das Unternehmen zwischen einer Katastrophe und der Wiederherstellung des Service hinnehmen kann. Kapitel 2
Red Teaming: Gezieltes gegnerisches Testen, bei dem Menschen oder Werkzeuge versuchen, ein System zu Fehlverhalten, Datenabfluss oder Schaden zu bringen, damit Schwachstellen gefunden werden, bevor Angreifer sie finden. Kapitel 12
RED-Methode: Tom Wilkies Checkliste für das Monitoring anfragegesteuerter Services: Rate, Errors und Duration (Rate, Fehler und Dauer) der Anfragen. Kapitel 9
Redundanz: Das Vorhalten mehrerer Exemplare einer Komponente, damit ein anderes übernehmen kann, wenn eines ausfällt. Kapitel 2
Refactoring: Die Änderung der inneren Struktur von Code, ohne sein äußeres Verhalten zu ändern, um ihn leichter verständlich und änderbar zu machen. Kapitel 1
Referenzarchitektur: Eine Musterarchitektur für eine Domäne oder Plattform, die typische Funktionen auf einen Standardsatz von Bausteinen abbildet und die Projekte anpassen, statt von Grund auf neu zu entwerfen. Kapitel 5
Region: Ein geografisches Gebiet, etwa Westeuropa oder Ost-USA, in dem ein Cloud-Anbieter eine eigene Gruppe von Rechenzentren betreibt. Regionen sind voneinander isoliert. Kapitel 0
Regressions-Eval: Eine automatisierte Evaluierung, die bei jeder Änderung an Prompts, Modellen, Retrieval oder Tools läuft und das Release blockiert, wenn die Qualität unter einen Schwellenwert oder eine Baseline fällt. Kapitel 12
Reinforcement Learning from Human Feedback (RLHF): Eine Trainingsphase, in der Menschen Modellantworten vergleichen, ein Belohnungsmodell ihre Präferenzen lernt und das Modell darauf optimiert wird, bei diesem gut abzuschneiden. Kapitel 12
Relationale Datenbank: Eine Datenbank, die Daten in Tabellen aus Zeilen und Spalten speichert und Tabellen über Schlüssel verknüpft. Sie wird mit SQL abgefragt. Kapitel 0
Replikation: Das Vorhalten von Kopien derselben Daten auf mehreren Maschinen für Verfügbarkeit, Lesekapazität und geringere Latenz in Nutzernähe. Kapitel 7
Replikationsverzögerung (Replication Lag): Die Verzögerung zwischen einem Schreibvorgang auf dem Leader und seinem Erscheinen auf einem Follower; sie führt dazu, dass Nutzer veraltete Daten lesen. Kapitel 7
Repository: Ein Objekt, das ganze Aggregate lädt und speichert und für die Domäne wie eine Sammlung aussieht, wobei es verbirgt, wie und wo sie gespeichert werden. Kapitel 5
Reproduzierbarer Build: Ein Build, der aus demselben Quellcode und denselben Eingaben bitgenau identische Ergebnisse erzeugt, sodass jeder neu bauen und prüfen kann, dass ein veröffentlichtes Artefakt nicht manipuliert wurde. Kapitel 8
Request Coalescing: Nur eine Anfrage holt ein fehlendes Element, während andere Anfragen nach demselben Element auf ihr Ergebnis warten und es mitnutzen; auch Single Flight genannt. Kapitel 7
Resilienz: Die umfassendere Fähigkeit eines Systems, Störungen aufzufangen, seinen wesentlichen Dienst (gegebenenfalls eingeschränkt) aufrechtzuerhalten und sich danach in den Normalzustand zurückzuversetzen. Kapitel 2
Resource Requests und Limits: Einstellungen für CPU und Arbeitsspeicher pro Container in Kubernetes: Requests reservieren Kapazität und steuern das Scheduling; Limits begrenzen die Nutzung, drosseln die CPU und beenden Container, die den Speicher überschreiten. Kapitel 10
REST (Representational State Transfer): Ein Architekturstil für Web-APIs, im Jahr 2000 von Roy Fielding beschrieben, bei dem Clients mit Standard-HTTP-Methoden auf Ressourcen einwirken, die durch URLs identifiziert werden. Kapitel 0
Retrieval-Augmented Generation (RAG): Das Abrufen relevanter Passagen aus eigenen Quellen zum Zeitpunkt der Abfrage und deren Übergabe an das Modell, damit es aus aktuellen, zulässigen und zitierfähigen Fakten antwortet. Kapitel 12
Retry-Budget: Eine Obergrenze für Wiederholungen, ausgedrückt als Anteil des normalen Datenverkehrs (zum Beispiel 10 %), damit Wiederholungen bei gelegentlichen Fehlern helfen, die Last während eines Ausfalls aber nicht vervielfachen können. Kapitel 9
Retry-Sturm: Eine Lastwelle, die entsteht, wenn viele Clients, oft auf mehreren Ebenen, fehlschlagende Anfragen gleichzeitig wiederholen, wodurch ein überlasteter Service überlastet bleibt. Kapitel 9
Reuse/Release Equivalence Principle (REP): Die Einheit der Wiederverwendung ist die Einheit des Release: Klassen, die zu einer Komponente zusammengefasst sind, sollten sich sinnvoll gemeinsam releasen, versionieren und wiederverwenden lassen. Kapitel 3
Rightsizing: Die Anpassung der Größe bereitgestellter Ressourcen (Maschinentypen, Container-Requests, Datenbankstufen) an das, was ein Workload tatsächlich nutzt. Kapitel 10
Risiko (in der Architekturbewertung): Eine Architekturentscheidung oder eine fehlende Entscheidung, die verhindern kann, dass das System eine wichtige Qualitätsanforderung oder ein wichtiges Geschäftsziel erfüllt. Kapitel 11
Risikogetriebenes Modell: George Fairbanks’ Ansatz, bei dem sich der Umfang der Architekturarbeit nach den Risiken richtet, denen ein Projekt gegenübersteht: Risiken erkennen, Techniken anwenden, die Risikominderung bewerten. Kapitel 1
Risikoregister: Eine gepflegte Liste erkannter Risiken mit Wahrscheinlichkeit, Auswirkung, Verantwortlichem, Gegenmaßnahme und Status, damit Risiken bis zu ihrem Abschluss verfolgt und nicht nach einem Meeting vergessen werden. Kapitel 11
Risikothema: Eine Gruppe zusammenhängender Risiken mit gemeinsamer Ursache, verknüpft mit den geschäftlichen Treibern, die sie gefährdet. Risikothemen sind für das Management meist das nützlichste Ergebnis einer Bewertung. Kapitel 11
Risk-Storming: Simon Browns kollaborative Technik, bei der Beteiligte zunächst schweigend Risiken mit Haftnotizen auf Architekturdiagrammen markieren, bewertet nach Wahrscheinlichkeit und Auswirkung, und sich dann annähern und Prioritäten und Gegenmaßnahmen vereinbaren. Kapitel 11
Roll-forward: Die Behebung eines fehlerhaften Release durch das Deployment einer neuen Korrektur statt der Rückkehr zur vorherigen Version. Kapitel 10
Rollback: Die Rückführung eines Systems auf einen früheren, als gut bekannten Zustand oder ein früheres Release, nachdem eine Änderung Probleme verursacht hat. Kapitel 2
Rollenbasierte Zugriffskontrolle (RBAC): Die Vergabe von Berechtigungen an Rollen und von Rollen an Benutzer, sodass der Zugriff über die Zuordnung von Personen zu Rollen wie Support-Mitarbeiter oder Restaurantleitung verwaltet wird. Kapitel 8
Rolling Deployment: Das Ersetzen der Instanzen eines Service in kleinen Gruppen, sodass alte und neue Version parallel laufen, bis alle Instanzen die neue Version ausführen. Kapitel 10
Rough Consensus: Eine Entscheidung, die erreicht ist, wenn jeder Einwand geprüft und beantwortet, aber nicht unbedingt berücksichtigt wurde; beschrieben in IETF RFC 7282. Kapitel 4
Runbook: Eine schriftliche, erprobte Anleitung, mit der eine bestimmte Betriebs- oder Sicherheitssituation Schritt für Schritt bewältigt wird, einschließlich der Prüfung und des Rollbacks jedes Schritts. Kapitel 8

S

SaaS (Software as a Service): Komplette Software, die über das Internet genutzt wird, meist über einen Browser oder eine App, wobei der Anbieter alles betreibt. Kapitel 0
Saga: Eine Geschäftstransaktion, umgesetzt als Folge lokaler Transaktionen, jede gepaart mit einer kompensierenden Transaktion, sodass entweder alle Schritte abgeschlossen oder bereits abgeschlossene Schritte semantisch rückgängig gemacht werden. 1987 von Garcia-Molina und Salem eingeführt. Kapitel 6
Saga-Gegenmaßnahme: Eine Entwurfstechnik, die Anomalien verringert, die durch die fehlende Isolation von Sagas entstehen, etwa ein semantisches Lock (ein Zustand PENDING), kommutative Änderungen oder das erneute Lesen eines Werts vor seiner Änderung. Kapitel 6
Saga-Orchestrator: Eine Komponente, die eine Saga koordiniert, indem sie Commands an die Beteiligten sendet, den Fortschritt in einem persistenten Zustandsautomaten verfolgt und bei Fehlern Kompensationen auslöst. Kapitel 6
Sandbox: Eine isolierte Umgebung mit eng begrenzten Berechtigungen, Netzwerkzugriff und Ressourcen, in der nicht vertrauenswürdiger Code, etwa von einem Modell geschriebener Code, sicher laufen kann. Kapitel 12
Scale Cube: Das Modell von Abbott und Fisher mit drei Arten der Skalierung: X-Achse (identische Kopien hinter einem Load Balancer), Y-Achse (Aufteilung nach Funktion) und Z-Achse (Aufteilung nach Daten, etwa nach Kunde). Kapitel 5
Schema: Die deklarierte Struktur einer Datenbank: ihre Tabellen, Spalten, Datentypen, Schlüssel und Regeln. Kapitel 0
Schema Registry: Ein Dienst, der jede Version jedes Nachrichtenschemas speichert und neue Versionen ablehnt, die gegen die vereinbarte Kompatibilitätsregel verstoßen. Kapitel 7
Schicht: Eine Gruppe von Komponenten mit derselben technischen Verantwortung, die der darüberliegenden Schicht Dienste anbietet und die darunterliegende Schicht nutzt. Kapitel 5
Schichtenarchitektur: Ein Stil, der Komponenten in horizontalen Schichten mit jeweils einer technischen Rolle anordnet, wobei jede Schicht nur die Schichten unter ihr nutzt. Kapitel 5
Schichtenbildung (Layering): Die Anordnung von Modulen in Schichten, wobei jede Schicht nur die Schichten unter ihr nutzen darf. Strikte Schichtenbildung erlaubt nur die direkt darunterliegende Schicht; lockere Schichtenbildung erlaubt jede tiefere Schicht. Kapitel 3
Schnittstelle: Die vereinbarte Menge von Operationen, die eine Software anderen anbietet, mit ihren Ein- und Ausgaben: ein Vertrag, der verbirgt, wie die Arbeit erledigt wird. Kapitel 0
Schweregrad: Eine vordefinierte Einstufung, wie schwerwiegend ein Incident ist, etwa SEV1 bis SEV4, die festlegt, wer alarmiert wird, wie schnell und wie breit kommuniziert wird. Kapitel 9
Scrum: Ein agiles Framework, in dem ein kleines Team in festen Zyklen von höchstens einem Monat, den Sprints, arbeitet, mit festgelegten Events, Verantwortlichkeiten und Artefakten. Kapitel 0
SDK (Software Development Kit): Eine Bibliothek, meist vom Eigentümer einer API bereitgestellt, die die HTTP-Aufrufe der API für eine bestimmte Programmiersprache in gewöhnliche Funktionen verpackt. Kapitel 0
Secrets-Management: Das Speichern, Verteilen, Rotieren und Auditieren von Zugangsdaten wie Passwörtern, API-Schlüsseln und privaten Schlüsseln in einem dedizierten Tresor (Vault) statt in Code oder Konfigurationsdateien. Kapitel 8
Secure by Default: Die Auslieferung eines Produkts, dessen Standardkonfiguration die sichere ist, sodass Benutzer sich bewusst dafür entscheiden müssen, den Schutz abzuschwächen, statt daran denken zu müssen, ihn einzuschalten. Kapitel 8
Secure Software Development Framework (SSDF): NIST SP 800-218: eine Sammlung von Praktiken für sichere Entwicklung, gruppiert in: die Organisation vorbereiten, die Software schützen, gut gesicherte Software erstellen und auf Schwachstellen reagieren. Kapitel 8
Sekundärindex: Ein Index auf ein anderes Attribut als den Primär- oder Partitionsschlüssel. In einem partitionierten Speicher ist er entweder lokal für jede Partition oder global und nach dem indexierten Wert partitioniert. Kapitel 7
Semantische Kopplung: Die Abhängigkeit von gemeinsamer Bedeutung oder gemeinsamen Geschäftsregeln, die in keiner Schnittstelle sichtbar ist, etwa bei zwei Services, die sich einig sein müssen, was „aktiver Kunde“ bedeutet. Kapitel 3
Semantische Versionierung: Eine Konvention zur Versionsnummerierung, MAJOR.MINOR.PATCH, bei der sich die Major-Nummer bei Breaking Changes ändert, die Minor-Nummer bei abwärtskompatiblen Ergänzungen und die Patch-Nummer bei Fehlerbehebungen. Kapitel 5
Semantisches Caching: Die Rückgabe einer gespeicherten Antwort, wenn eine neue Abfrage einer früheren inhaltlich ähnelt, beurteilt durch den Vergleich von Embeddings, ohne das Modell aufzurufen. Kapitel 12
Sensitivitätspunkt: Eine Eigenschaft einer oder mehrerer Komponenten oder Verbindungen, die entscheidend dafür ist, eine bestimmte Qualitätsantwort zu erreichen, etwa die Anzahl synchroner Hops auf dem Bestellpfad. Kapitel 11
Sequenzdiagramm: Ein UML-Diagramm, das die zwischen Teilnehmern ausgetauschten Nachrichten für ein Szenario im zeitlichen Verlauf zeigt, wobei die Zeit von oben nach unten verläuft. Kapitel 4
Sequenzielle Konsistenz: Ein Konsistenzmodell, bei dem alle Clients die Operationen in einer gemeinsamen Reihenfolge sehen, die die Reihenfolge jedes einzelnen Clients bewahrt, aber nicht der realen Zeit entsprechen muss. Kapitel 6
Serialisierbarkeit: Die stärkste Isolationsgarantie: Nebenläufige Transaktionen liefern dasselbe Ergebnis, als wären sie in irgendeiner Reihenfolge nacheinander ausgeführt worden. Kapitel 7
Server: Ein Computer oder ein darauf laufendes Programm, der auf Anfragen anderer Computer (Clients) wartet und sie beantwortet. Kapitel 0
Serverless: Ein Cloud-Modell, bei dem der Anbieter Ihre Funktionen oder Workflows bei Bedarf ausführt und nach Nutzung abrechnet, sodass Sie selbst keine Server verwalten. Kapitel 1
Serverless und FaaS (Function as a Service): Ein Cloud-Modell, bei dem Sie einzelne Funktionen hochladen, die nur laufen, wenn ein Ereignis sie auslöst; der Anbieter kümmert sich um alle Server, und Sie bezahlen pro Ausführung. Kapitel 0
Service (Kubernetes): Ein Kubernetes-Objekt, das einer wechselnden Menge von Pods einen stabilen Namen und eine virtuelle Adresse gibt und den Datenverkehr auf sie verteilt. Kapitel 10
Service Discovery: Ein Mechanismus, etwa eine Registry oder DNS, über den Clients die aktuellen Netzwerkadressen funktionsfähiger Service-Instanzen finden. Kapitel 6
Service Level Agreement (SLA): Ein Vertrag mit Kunden, der ein Service-Level und die Folgen bei Nichteinhaltung festlegt, etwa Service-Gutschriften. Kapitel 2
Service Level Indicator (SLI): Eine sorgfältig definierte Messgröße für das Verhalten eines Service, etwa der Anteil der Anfragen, die in weniger als 300 ms erfolgreich sind. Kapitel 2
Service Level Objective (SLO): Ein internes Ziel für einen SLI über ein Zeitfenster, etwa 99,9 % erfolgreiche Anfragen über 30 Tage. Kapitel 2
Service Mesh: Eine zentral konfigurierte Infrastrukturschicht aus Netzwerk-Proxys, die Verschlüsselung zwischen Services, Wiederholungen, Timeouts, Traffic-Steuerung und Telemetrie bereitstellt. Kapitel 6
Service-Gutschrift: Eine Erstattung oder ein Rabatt, der einem Kunden nach einem SLA zusteht, wenn der Anbieter ein zugesagtes Service-Level verfehlt. Kapitel 9
Servicebasierte Architektur: Ein verteilter Stil mit wenigen grobgranularen, separat deployten Domain-Services (typischerweise 4 bis 12), die sich oft eine Datenbank teilen; von Mark Richards und Neal Ford benannt. Kapitel 6
Serviceorientierte Architektur (SOA): Ein Ansatz, der ab Anfang der 2000er-Jahre in Unternehmen vorherrschte und fachliche Fähigkeiten als gemeinsam genutzte Services mit expliziten Verträgen bereitstellt, typischerweise über einen Enterprise Service Bus verbunden. Kapitel 6
Session Guarantees: Konsistenzzusagen pro Client, 1994 von Terry und Kollegen beschrieben: Read-your-Writes, Monotonic Reads, Monotonic Writes und Writes-follow-Reads. Kapitel 6
Shadow Traffic (Dark Launch): Das Kopieren echter Anfragen an eine neue Version, deren Antworten verglichen oder verworfen, aber nie an Nutzer zurückgegeben werden, um sie unter realer Last ohne Auswirkungen auf Nutzer zu testen. Kapitel 10
Shared Kernel: Ein kleiner Teil eines Modells samt Code, den zwei Kontexte ausdrücklich gemeinsam nutzen und der nur mit Zustimmung beider Teams geändert werden darf. Kapitel 5
Shift Left: Die Verlagerung von Sicherheitsaktivitäten (oder Tests) auf frühere Phasen des Entwicklungslebenszyklus, in Anforderungen, Entwurf und Programmierung, wo Probleme billiger zu beheben sind als in der Produktion. Kapitel 8
Showback: Die Ausweisung der jedem Team oder Produkt zugeordneten Kosten, ohne dessen Budget tatsächlich zu belasten. Kapitel 10
Shuffle Sharding: Die Zuordnung jedes Kunden zu einer kleinen, zufällig gewählten Kombination von Ressourcen, sodass zwei Kunden selten alle Ressourcen gemeinsam haben und ein problematischer Kunde nur wenige andere beeinträchtigt. Kapitel 10
Sicht: Eine Darstellung einer oder mehrerer Strukturen eines Systems, ausgerichtet auf bestimmte Anliegen bestimmter Stakeholder, etwa ein Deployment-Diagramm für das Betriebspersonal. Kapitel 1
Sichtkomponente: In ISO/IEC/IEEE 42010:2022 ein Bestandteil einer Sicht, etwa ein Diagramm, eine Tabelle oder ein Modell, der von einer Modellart bestimmt wird. Die Ausgabe von 2011 nannte ihn Architekturmodell. Kapitel 4
SIEM: Security Information and Event Management: ein System, das Sicherheitslogs aus vielen Quellen sammelt, korreliert und Alarme auslöst, wenn sie Erkennungsregeln entsprechen. Kapitel 8
Sigstore: Ein Open-Source-Projekt zum Signieren und Verifizieren von Software-Artefakten mit kurzlebigen, an eine Identität gebundenen Zertifikaten und einem öffentlichen Transparenzlog, das langlebige Signierschlüssel überflüssig macht. Kapitel 8
Single Responsibility Principle (SRP): Ein Modul sollte einem einzigen Akteur verantwortlich sein: einer Gruppe von Menschen, die seine Änderungen anfordern. Code, der sich aus verschiedenen Gründen auf Wunsch verschiedener Personen ändert, sollte getrennt gehalten werden. Kapitel 3
Skalierbarkeit: Die Fähigkeit eines Systems, durch zusätzliche Ressourcen mehr Last zu bewältigen, idealerweise mit einem vorhersehbaren und annähernd proportionalen Anstieg von Kapazität und Kosten. Kapitel 2
SLSA: Supply-chain Levels for Software Artifacts: ein Framework mit aufsteigenden Stufen der Gewissheit, dass ein Artefakt durch einen vertrauenswürdigen, manipulationssicheren Build aus dem erwarteten Quellcode erstellt wurde. Kapitel 8
Snapshot: Eine gespeicherte Kopie des Zustands eines Aggregats bei einer bekannten Event-Version, die verhindert, dass ein langer Stream von Anfang an neu abgespielt werden muss; sie ist ein Cache, keine maßgebliche Datenquelle. Kapitel 7
Snapshot Isolation: Eine Isolationsebene, bei der jede Transaktion ab ihrem Beginn einen konsistenten Snapshot der bestätigten Daten liest und widersprüchliche Schreibvorgänge auf dieselbe Zeile abgewiesen werden. Sie verhindert Lost Updates, lässt aber Write Skew zu. Kapitel 7
Soak-Test: Ein langer Performance-Test unter normaler Last, der über Stunden oder Tage läuft, um schleichende Probleme wie Speicherlecks oder wachsende Warteschlangen aufzudecken; auch Dauertest (Endurance Test) genannt. Kapitel 9
Software: Programme zusammen mit den Daten und der Konfiguration, die sie benötigen; die Anweisungen, die der Hardware sagen, was sie tun soll. Kapitel 0
Software Bill of Materials (SBOM): Ein maschinenlesbares Verzeichnis der Komponenten und Abhängigkeiten einer Software in einem Standardformat wie SPDX oder CycloneDX. Kapitel 8
Software Carbon Intensity (SCI): Eine Spezifikation der Green Software Foundation, veröffentlicht als ISO/IEC 21031:2024, die die CO₂-Emissionen von Software als Rate ausdrückt: ((Energie x CO₂-Intensität des Stromnetzes) + graue Emissionen) pro funktionaler Einheit. Kapitel 2
Software Carbon Intensity (SCI): Die Spezifikation der Green Software Foundation, veröffentlicht als ISO/IEC 21031:2024, die Software als ((E × I) + M) pro R bewertet: Energie mal CO₂-Intensität des Stromnetzes plus graue Emissionen, pro funktionaler Einheit. Kapitel 11
Software Composition Analysis (SCA): Werkzeuge und Praktiken, die die Open-Source-Komponenten in Software ermitteln und mit Datenbanken bekannter Schwachstellen und Lizenzen abgleichen. Kapitel 8
Software Design Description (SDD): Ein Dokument, das einen Softwareentwurf im Detail beschreibt und dessen Inhalt IEEE Std 1016-2009 festlegt; verbreitet in vertragsgetriebenen Projekten. Kapitel 4
Software-Supply-Chain-Angriff: Ein Angriff, der etwas kompromittiert, das eine Organisation bezieht, etwa eine Abhängigkeit, ein Build-Werkzeug, ein Update oder eine Registry, um diese Organisation und weitere nachgelagerte zu erreichen. Kapitel 8
Softwarearchitektur: Die grundlegenden Strukturen eines Softwaresystems und die wesentlichen Entscheidungen, die sie geprägt haben: seine Hauptbestandteile, wie sie zusammenhängen, ihre wichtigen Eigenschaften und die Prinzipien, nach denen es gebaut und weiterentwickelt wird. Kapitel 1
Softwaresystem (C4): Im C4-Modell die höchste Abstraktionsebene: etwas, das seinen Nutzern einen Wert liefert, meist im Besitz eines Teams oder einer Organisation. Kapitel 4
SOLID: Ein Merkwort für fünf von Robert C. Martin zusammengestellte Prinzipien des objektorientierten Entwurfs: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation und Dependency Inversion. Kapitel 3
Soziotechnische Architektur: Der gemeinsame Entwurf von Softwarestruktur und Teamstruktur, weil jede die andere prägt. Die Idee geht auf die Forschung zu soziotechnischen Systemen am Tavistock Institute zurück, beginnend mit Eric Trists und Ken Bamforths Studie zum Kohlebergbau von 1951. Kapitel 11
Space-Based Architecture: Ein Architekturstil, der Anfragen über viele identische Verarbeitungseinheiten bedient, die Daten in replizierten In-Memory-Grids halten und die Datenbank asynchron aktualisieren, sodass sie aus dem Anfragepfad herausgenommen ist. Kapitel 6
SPACE-Framework: Ein Framework von 2021 für die Produktivität von Entwicklern, das Zufriedenheit und Wohlbefinden, Leistung, Aktivität, Kommunikation und Zusammenarbeit sowie Effizienz und Flow abdeckt. Kapitel 10
Span: Eine zeitlich gemessene Operation innerhalb eines Trace, etwa ein HTTP-Aufruf oder eine Datenbankabfrage, mit Name, Startzeit, Dauer, Attributen und einer Verknüpfung zu ihrem übergeordneten Span. Kapitel 9
Spike: Eine kurze, zeitlich begrenzte Untersuchung oder ein Prototyp, um eine technische Frage zu beantworten oder ein Risiko zu verringern, und der danach normalerweise verworfen wird. Kapitel 1
Spike-Test: Ein Performance-Test, der die Last plötzlich erhöht, zum Beispiel innerhalb von Sekunden auf das Zehnfache, um Autoscaling, Warteschlangen und Schutzmechanismen zu prüfen. Kapitel 9
Split Brain: Ein Fehlerzustand, bei dem zwei Knoten beide glauben, der Leader zu sein, und beide Schreibvorgänge annehmen, sodass ihre Daten auseinanderlaufen. Kapitel 7
Spot-Kapazität: Freie Cloud-Kapazität, die mit hohem Rabatt verkauft wird und die der Anbieter kurzfristig zurückfordern kann; nur für Arbeit geeignet, die Unterbrechungen verträgt. Kapitel 10
SQL (Structured Query Language): Die Standardsprache zum Definieren, Abfragen und Ändern von Daten in relationalen Datenbanken. Sie beschreiben das gewünschte Ergebnis, und die Datenbank ermittelt, wie sie es erhält. Kapitel 0
Stable Abstractions Principle: Robert C. Martins Prinzip, dass eine Komponente so abstrakt sein sollte, wie sie stabil ist, damit stabile Komponenten trotzdem erweitert werden können. Kapitel 3
Stable Dependencies Principle: Robert C. Martins Prinzip, dass eine Komponente nur von Komponenten abhängen sollte, die stabiler sind als sie selbst: Abhängigkeiten in Richtung der Stabilität. Kapitel 3
Staff Engineer: Eine Senior-Rolle als Individual Contributor oberhalb des Senior Engineer, die teamübergreifende technische Führung ohne Personalverantwortung umfasst; Principal Engineer ist meist die nächsthöhere Stufe. Kapitel 1
Staff-plus Engineer: Ein erfahrener Individual Contributor (Staff, Principal oder Distinguished Engineer), der teamübergreifend technische Führung ausübt, ohne Personalverantwortung zu tragen; ein von Will Larson populär gemachter Begriff. Kapitel 11
Stakeholder: Eine Person, ein Team oder eine Organisation mit einem Interesse an einem System, etwa Nutzer, Auftraggeber, Entwickler, Betrieb, Sicherheitsverantwortliche oder Aufsichtsbehörden. Kapitel 1
Stapelverarbeitung (Batch Processing): Die Verarbeitung einer abgegrenzten Datenmenge in einem Durchlauf, etwa aller Bestellungen von gestern, mit anschließendem Abschluss. Kapitel 5
Stärke (der Connascence): Wie schwer eine Form der Connascence zu entdecken und zu refaktorisieren ist. Name ist die schwächste Form; dynamische Formen wie Timing, Value und Identity gehören zu den stärksten. Kapitel 3
State (Infrastructure as Code): Die Aufzeichnung, die ein Infrastrukturwerkzeug darüber führt, welche realen Ressourcen welchen Definitionen im Code entsprechen, und anhand derer es ermittelt, was zu erstellen, zu ändern oder zu löschen ist. Kapitel 10
Statische Connascence: Connascence, die im Quellcode erkennbar ist, ohne ihn auszuführen, etwa die Übereinstimmung bei einem Namen, einem Typ, der Bedeutung eines Werts, der Reihenfolge von Parametern oder einem Algorithmus. Kapitel 3
Statische Stabilität: Die Eigenschaft, dass ein System während eines Ausfalls weiterarbeitet, ohne im Moment des Ausfalls Änderungen vornehmen zu müssen, etwa neue Server zu starten oder die Konfiguration zu aktualisieren. Kapitel 10
Statusseite: Eine öffentliche oder für Kunden bestimmte Seite, die über aktuelle Incidents und den Zustand der Services informiert und von der für die Kommunikation zuständigen Person des Incidents aktualisiert wird. Kapitel 9
Steady-State-Hypothese: In einem Chaos-Experiment die Vorhersage, dass ein messbares Anzeichen für normales Verhalten, etwa Bestellungen pro Minute, innerhalb festgelegter Grenzen bleibt, während ein Fehler eingespeist wird. Kapitel 9
Sternschema: Ein dimensionales Modell mit einer zentralen Faktentabelle aus Messwerten, umgeben von Dimensionstabellen, die diese beschreiben, etwa Datum, Kunde und Produkt. Kapitel 7
Sticky Session (Session-Affinität): Eine Load-Balancer-Einstellung, die alle Anfragen eines Clients an dieselbe Instanz schickt, meist damit Sitzungsdaten im Speicher dieser Instanz gefunden werden. Kapitel 9
Stimulus: Das Ereignis, um das es in einem Qualitätsszenario geht, etwa ein Anfrageschub, ein Serverabsturz, ein Änderungswunsch oder ein Angriff. Kapitel 2
Strangler Fig: Ein schrittweiser Modernisierungsansatz, von Martin Fowler benannt, bei dem neue Komponenten hinter einer Abfangschicht nach und nach Verhalten eines Altsystems übernehmen, bis das alte System abgeschaltet werden kann. Kapitel 11
Stream Processing: Die kontinuierliche Verarbeitung eines unbegrenzten Stroms von Datensätzen, jeder kurz nach seinem Eintreffen. Kapitel 5
Stream-aligned Team: Ein langlebiges, funktionsübergreifendes Team, das auf einen Änderungsstrom ausgerichtet ist, etwa ein Produkt, eine User Journey oder eine fachliche Fähigkeit, und seinen Teil durchgängig bauen, betreiben und ändern kann. Die meisten Teams einer Organisation sollten von diesem Typ sein. Kapitel 11
Stresstest: Ein Performance-Test, der die Last über die erwartete Spitze hinaus steigert, um zu sehen, wie das System versagt und ob es sich erholt. Kapitel 9
STRIDE: Ein Merkwort für sechs Arten von Bedrohungen (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service und Elevation of Privilege), 1999 bei Microsoft von Loren Kohnfelder und Praerit Garg entwickelt. Kapitel 8
Structurizr: Simon Browns Werkzeuge für das C4-Modell, bei denen ein textbasiertes Modell viele konsistente Diagramme erzeugt. Kapitel 4
Struktur: Eine Menge von Elementen und den Beziehungen zwischen ihnen, aus einem bestimmten Blickwinkel betrachtet: zum Beispiel die Codemodule und ihre Abhängigkeiten oder die laufenden Services und wie sie kommunizieren. Kapitel 1
Strukturierte Ausgabe: Modellausgabe, die auf ein deklariertes Format beschränkt ist, meist ein JSON Schema, damit die Anwendung sie zuverlässig parsen und validieren kann. Kapitel 12
Strukturiertes Logging: Das Schreiben von Logeinträgen als maschinenlesbare Schlüssel-Wert-Datensätze (oft JSON) mit einheitlichen Feldnamen statt als Freitextsätze. Kapitel 9
Stückkosten: Die Betriebskosten eines Systems geteilt durch eine Einheit nützlicher Arbeit, etwa Kosten pro Bestellung oder pro aktivem Nutzer, damit sich die Effizienz verfolgen lässt, während das Unternehmen wächst. Kapitel 2
Subdomäne: Ein abgegrenzter Bereich der Geschäftstätigkeit eines Unternehmens, etwa Speisekarten, Bestellungen, Zahlungen oder Disposition. Subdomänen gehören zum Problem, unabhängig davon, ob es Software gibt. Kapitel 5
Suchmaschine: Ein Speicher, der auf einem invertierten Index von Wörtern auf Dokumente aufbaut und eine nach Relevanz sortierte, tippfehlertolerante Volltextsuche bietet; meist aus einem System of Record gespeist. Kapitel 7
Supporting Subdomain: Eine Subdomäne, die spezifisch für das Unternehmen und für es notwendig ist, in der es aber nicht im Wettbewerb steht; sie verdient einen soliden, aber einfacheren Entwurf. Kapitel 5
Symmetrische Verschlüsselung: Verschlüsselung, bei der derselbe geheime Schlüssel ver- und entschlüsselt, etwa AES; schnell und daher für große Datenmengen verwendet. Kapitel 8
Synchrone Kommunikation: Eine Interaktion, bei der der Aufrufer eine Anfrage sendet und auf die Antwort wartet, bevor er fortfährt, wie bei einem Telefonat. Beide Seiten müssen im selben Moment verfügbar sein. Kapitel 6
Synchroner Aufruf: Eine Anfrage, bei der der Aufrufer auf die Antwort wartet, bevor er fortfährt, wie bei einem gewöhnlichen HTTP-API-Aufruf. Kapitel 0
System of Record: Die maßgebliche Quelle für ein Datum, deren Wert gilt, wenn Kopien voneinander abweichen, etwa das Kernbuchungssystem einer Bank für Kontostände. Kapitel 7
Systemkontextdiagramm: Ein C4-Diagramm, das ein System als einzelnen Kasten zeigt, zusammen mit den Personen, die es nutzen, und den anderen Systemen, mit denen es interagiert. Kapitel 4

T

Tail-Latenz: Die Antwortzeiten der langsamsten Anfragen, meist durch hohe Perzentile wie p99 oder p99,9 beschrieben. Bei großer Skalierung entscheidet oft das Ende der Verteilung darüber, was Nutzer erleben. Kapitel 2
Taktik: Eine Entwurfsentscheidung, die beeinflusst, wie ein System auf einen Qualitätsstimulus reagiert, etwa Caching zur Senkung der Latenz oder Redundanz, um einen Absturz zu überstehen. Taktiken sind die Bausteine von Mustern. Kapitel 2
TARA: Der Tiny Architectural Review Approach, Eoin Woods’ leichtgewichtige Methode zur Bewertung eines bestehenden Systems, die Expertenurteil mit automatisierter Analyse seines Codes und seiner Laufzeitdaten verbindet. Kapitel 11
TCP: Transmission Control Protocol: liefert einen zuverlässigen, geordneten Datenstrom zwischen zwei Programmen und sendet verlorene Pakete erneut. Der meiste Webverkehr lief traditionell darüber. Kapitel 0
Team Topologies: Ein Ansatz zur Organisation von Softwareteams für einen schnellen Fluss, dargelegt von Matthew Skelton und Manuel Pais im gleichnamigen Buch (2019; zweite Auflage 2025): vier Teamtypen, drei Interaktionsmodi und die kognitive Last des Teams als zentrale Randbedingung. Kapitel 11
Team-API: Alles, was ein Team anderen Teams anbietet und von ihnen erwartet: seine Code-Schnittstellen, Dokumentation, Versionierungsregeln, Arbeitsweisen, Kommunikationskanäle und wie man Arbeit bei ihm anfragt. Kapitel 11
Technische Breite: Das Wissen, dass es viele Technologien und Ansätze gibt, was sie gut und schlecht können und wann man sie einsetzt, auch ohne tiefe praktische Erfahrung mit jedem einzelnen. Kapitel 1
Technische Partitionierung: Die Aufteilung der obersten Struktur eines Systems nach technischer Rolle, etwa Benutzeroberfläche, Geschäftslogik und Datenzugriff. Kapitel 5
Technische Schulden: Die zusätzlichen künftigen Änderungskosten, verursacht durch Abkürzungen oder durch einen Entwurf, der nicht mehr passt, bezahlt in Form langsamerer und riskanterer Arbeit, bis sie durch eine Verbesserung des Entwurfs getilgt werden. Kapitel 1
Technologieradar: Eine regelmäßig aktualisierte Landkarte von Technologien und Techniken, in Quadranten gruppiert und auf Ringe wie Adopt, Trial, Assess und Hold verteilt (in neueren Ausgaben von Thoughtworks in Caution umbenannt), bekannt gemacht durch Thoughtworks. Kapitel 11
Teilausfall: Eine Situation, in der einige Teile eines verteilten Systems funktionieren, während andere ausgefallen, langsam oder nicht erreichbar sind, oft ohne dass die funktionierenden Teile erkennen können, welche. Kapitel 6
Teilmerkmal: Eine spezifischere Qualität innerhalb eines Merkmals eines Qualitätsmodells; so sind Fehlertoleranz und Wiederherstellbarkeit in ISO/IEC 25010 Teilmerkmale der Zuverlässigkeit. Kapitel 2
Telemetrie: Daten, die ein laufendes System über sein eigenes Verhalten ausgibt: Logs, Metriken, Traces, Profile und Ereignisse. Kapitel 9
Temperature: Eine Sampling-Einstellung, die die Wahrscheinlichkeiten des Modells für das nächste Token schärft (unter 1) oder abflacht (über 1) und die Ausgabe so wiederholbarer oder vielfältiger macht. Kapitel 12
Test Double: Ein Ersatz für einen echten Kollaborateur in einem Test, etwa ein Stub mit vorgefertigten Antworten, ein Fake mit einer einfachen funktionierenden Implementierung oder ein Mock, der die empfangenen Aufrufe prüft. Kapitel 2
Testbarkeit: Wie leicht sich durch Tests zeigen lässt, dass sich ein System oder eine Komponente wie vorgesehen verhält; das hängt davon ab, ob sich Eingaben und Zustand steuern und Ausgaben beobachten lassen. Kapitel 2
Testpyramide: Eine Orientierungshilfe von Mike Cohn für das Verhältnis automatisierter Tests: viele schnelle Unit-Tests, weniger Integrationstests und nur wenige langsame End-to-End-Tests. Kapitel 0
Thinnest Viable Platform: Die kleinste Menge gemeinsamer Dienste und Dokumentation, die Produktteams tatsächlich schneller macht; die Warnung von Team Topologies davor, mehr Plattform zu bauen als nötig. Kapitel 10
Thread: Eine Folge von Anweisungen, die innerhalb eines Prozesses ausgeführt wird. Threads desselben Prozesses teilen sich dessen Speicher, sodass sie gleichzeitig arbeiten können, sich aber abstimmen müssen. Kapitel 0
Tiefes Modul: Der Begriff von John Ousterhout für ein Modul, dessen einfache Schnittstelle viel Funktionalität verbirgt. Ein flaches Modul bietet für die Komplexität seiner Schnittstelle wenig Verhalten. Kapitel 3
Tier: Eine physische Grenze zur Laufzeit, etwa ein separater Prozess oder Server. Eine Schicht ist eine logische Grenze im Code; mehrere Schichten können in einem Tier laufen. Kapitel 5
Tilgungsaufwand (technischer Schulden): Der Aufwand, der nötig ist, um ein Stück technischer Schulden zu beheben, also Code oder Struktur in den Zustand zu bringen, in dem sie sein sollten. Kapitel 1
Time to First Token (TTFT): Die Verzögerung zwischen dem Senden einer Anfrage an ein Modell und dem Empfang des ersten Tokens seiner Antwort. Kapitel 12
Time to Live (TTL): Wie lange ein zwischengespeichertes Element verwendet werden darf, bevor es als veraltet gilt und aufgefrischt oder neu validiert werden muss. Kapitel 7
Timeout: Die maximale Zeit, die ein Aufrufer auf eine Operation wartet, bevor er aufgibt und sie als fehlgeschlagen behandelt; jeder entfernte Aufruf braucht einen. Kapitel 9
TLS und HTTPS: Transport Layer Security verschlüsselt Daten zwischen zwei Programmen und weist über Zertifikate die Identität des Servers nach. HTTPS ist HTTP über TLS. Kapitel 0
TOGAF: Das Open Group Architecture Framework, ein weit verbreitetes Framework und eine Methode für Unternehmensarchitektur, herausgegeben von The Open Group; die aktuelle Version ist der TOGAF Standard, 10th Edition (2022). Kapitel 1
Token: Die Texteinheit, die ein Sprachmodell liest und schreibt: ein Wort oder Wortteil aus einem festen Vokabular. Grenzen, Preise und Geschwindigkeit werden alle in Tokens gezählt. Kapitel 12
Token Bucket: Ein Algorithmus für Rate Limiting, bei dem einem Eimer mit fester Rate Tokens bis zu einer Kapazität hinzugefügt werden und jede Anfrage ein Token verbraucht; er erlaubt Lastspitzen bis zur Kapazität und eine gleichmäßige Durchschnittsrate. Kapitel 9
Tokenisierung: Das Ersetzen eines sensiblen Werts wie einer Kartennummer durch ein bedeutungsloses Token, während der echte Wert in einem separaten, streng geschützten Tresor aufbewahrt wird, der oft von einem Zahlungsdienstleister betrieben wird. Kapitel 8
Tolerant Reader: Ein Consumer, der nur die Felder liest, die er braucht, und alles ignoriert, was er nicht kennt, sodass Anbieter Felder hinzufügen können, ohne ihn zu beschädigen. Kapitel 7
Tool Calling: Eine Modellfähigkeit, bei der das Modell eine strukturierte Anfrage zurückgibt, eine von der Anwendung beschriebene Funktion aufzurufen; die Anwendung, nicht das Modell, führt sie aus. Kapitel 12
Toter Code: Code, der nicht mehr ausgeführt werden soll, aber im deployten System noch vorhanden ist, wo er versehentlich ausgelöst werden kann. Kapitel 1
Trace-Sampling: Das Aufbewahren nur eines Teils der Traces, um die Kosten zu begrenzen: Head-based Sampling entscheidet zu Beginn einer Anfrage, Tail-based Sampling nach ihrem Ende, sodass es langsame und fehlgeschlagene Anfragen behalten kann. Kapitel 9
Trade-off-Punkt: Eine Architekturentscheidung, die mehr als ein Qualitätsmerkmal beeinflusst und eines verbessert, während sie einem anderen schadet. Kapitel 2
Transactional Outbox: Ein Muster, bei dem ein Service ausgehende Nachrichten in derselben lokalen Transaktion wie seine fachliche Änderung in eine Outbox-Tabelle schreibt; ein Relay veröffentlicht sie später und erreicht so At-least-once-Zustellung ohne verteilte Transaktion. Kapitel 6
Transaktion: Eine Gruppe von Datenbankoperationen, die als eine Einheit behandelt wird: Entweder werden alle wirksam (Commit) oder keine (Rollback). Kapitel 0
Transformer: Die von Vaswani und Kollegen 2017 eingeführte Architektur neuronaler Netze auf Basis von Self-Attention, die heutigen großen Sprachmodellen und den meisten Embedding-Modellen zugrunde liegt. Kapitel 12
Transitive Abhängigkeit: Ein Paket, das Ihre Software indirekt nutzt, weil eine Ihrer Abhängigkeiten oder eine von deren Abhängigkeiten darauf angewiesen ist. Kapitel 8
Treibender (primärer) Adapter: Ein Adapter, der Anfragen von außen entgegennimmt, etwa ein Web-Controller, ein Test-Harness oder ein geplanter Job, und die Anwendung über einen treibenden Port aufruft. Kapitel 5
Trunk-Based Development: Eine Arbeitsweise, bei der Entwickler kleine Änderungen mindestens täglich in einen gemeinsamen Hauptbranch integrieren, statt langlebige Feature-Branches zu pflegen. Kapitel 10
Tuple Space: Ein gemeinsamer assoziativer Speicher, in den Prozesse Tupel schreiben und aus dem sie passende Tupel lesen oder entnehmen, ohne voneinander zu wissen. Eingeführt mit David Gelernters Sprache Linda (1985). Kapitel 6
Twelve-Factor App: Eine Methodik aus zwölf Praktiken für den Bau deploybarer, skalierbarer Webanwendungen, 2011 von Adam Wiggins bei Heroku verfasst und 2024 als Open Source freigegeben. Kapitel 10
Two-Phase Commit (2PC): Ein Protokoll, das mehrere Beteiligte gemeinsam committen oder abbrechen lässt: Ein Koordinator fordert zunächst alle auf, sich vorzubereiten und abzustimmen, und teilt dann allen das Ergebnis mit. Beteiligte, die mit Ja gestimmt haben, blockieren, wenn der Koordinator ausfällt. Kapitel 6

U

Übergangsarchitektur: Temporäre Software wie Routing-Schichten, Adapter und Synchronisierungsjobs, die nur gebaut wird, damit alte und neue Systeme während einer Migration nebeneinander bestehen können, und nach deren Abschluss entfernt wird. Kapitel 11
Übermäßige Handlungsbefugnis (Excessive Agency): Einem KI-System mehr Werkzeuge, Berechtigungen oder Autonomie geben, als seine Aufgabe erfordert, sodass ein manipuliertes oder irrendes Modell echten Schaden anrichten kann. Kapitel 12
Überwachtes Lernen: Maschinelles Lernen aus gelabelten Beispielen, bei dem jede Trainingseingabe mit der richtigen Antwort versehen ist, etwa Zahlungen, die als betrügerisch oder echt markiert sind. Kapitel 12
Ubiquitous Language: Ein Vokabular, das Entwickler und Fachexperten teilen und innerhalb eines Bounded Context einheitlich in Gesprächen, Dokumenten, Tests und Code verwenden. Kapitel 5
UDP: User Datagram Protocol: sendet einzelne Pakete ohne Garantie für Zustellung oder Reihenfolge. Schneller und einfacher als TCP; verwendet für Videoanrufe, Spiele und DNS. Kapitel 0
Umgebung: Eine separate, vollständige Kopie des Systems und seiner Einstellungen für einen bestimmten Zweck, etwa Entwicklung, Test, Staging oder Produktion. Kapitel 0
Umkehrbarkeit: Wie kostengünstig und sicher sich eine Entscheidung rückgängig machen lässt. Gut umkehrbare Entscheidungen können schnell getroffen werden; irreversible verdienen mehr Analyse. Kapitel 1
Unabhängige Deploybarkeit: Die Fähigkeit, einen Service zu ändern und in Produktion zu releasen, ohne gleichzeitig einen anderen Service ändern, testen oder releasen zu müssen. Kapitel 6
Unified Modeling Language (UML): Eine universelle grafische Modellierungssprache, standardisiert von der Object Management Group. Die aktuelle Version ist 2.5.1 (2017). Kapitel 4
Unit Economics: Die Angabe von Kosten (und Erlösen) pro Einheit geschäftlichen Werts, etwa Kosten pro Bestellung oder pro aktivem Kunden, damit sich die Effizienz unabhängig vom Wachstum beurteilen lässt. Kapitel 10
Unit-Test: Ein automatisierter Test, der ein kleines Stück Code, etwa eine Funktion, isoliert prüft und in Millisekunden läuft. Kapitel 0
Universal Scalability Law (USL): Neil Gunthers Modell dafür, wie die Kapazität mit zusätzlichen Knoten wächst, unter Berücksichtigung der Konkurrenz um gemeinsame Ressourcen und der Kosten, Daten kohärent zu halten. Es sagt ein Maximum voraus, ab dem weitere Knoten die Kapazität verringern. Kapitel 2
Unternehmensarchitektur: Architektur auf der Ebene einer ganzen Organisation: wie ihre Geschäftsfähigkeiten, Informationen, Anwendungen und Technologien zusammenpassen und sich im Laufe der Zeit verändern. Kapitel 1
Unüberwachtes Lernen: Maschinelles Lernen ohne Labels, bei dem das Modell selbst Strukturen findet, etwa Gruppen ähnlicher Kunden oder ungewöhnliche Transaktionen. Kapitel 12
Unveränderliches Backup: Eine Sicherungskopie, die vor Ablauf ihrer Aufbewahrungsfrist nicht geändert oder gelöscht werden kann, auch nicht von einem Administrator, und so vor Ransomware und böswilligen Insidern geschützt ist. Kapitel 8
Upcasting: Die Umwandlung eines in einer alten Schemaversion gespeicherten Ereignisses in die aktuelle Version beim Lesen, sodass der Anwendungscode nur eine Form verarbeiten muss. Kapitel 7
USE-Methode: Brendan Greggs Checkliste zur Analyse von Ressourcen: Prüfen Sie für jede Ressource Utilisation, Saturation und Errors (Auslastung, Sättigung und Fehler). Kapitel 9
User Story: Eine kurze Beschreibung eines Features aus Sicht der Person, die es sich wünscht, oft formuliert als: Als [Rolle] möchte ich [Fähigkeit], damit [Nutzen]. Kapitel 0
UTF-8: Die vorherrschende Art, Text als Bytes zu codieren. Sie kann jedes Unicode-Zeichen darstellen und verwendet ein Byte für einfache lateinische Buchstaben und bis zu vier Bytes für andere. Kapitel 0
Utility Tree: Ein Baum aus der ATAM, der den Gesamtnutzen in Qualitätsmerkmale und dann in konkrete Szenarien verfeinert, die jeweils nach geschäftlicher Bedeutung und technischer Schwierigkeit bewertet werden. Kapitel 2

V

Value Object: Ein Domänenobjekt, das allein durch seine Werte definiert ist, keine eigene Identität hat und meist unveränderlich ist, etwa ein Geldbetrag oder eine Adresse. Kapitel 5
Vektordatenbank: Ein Speicher für Embeddings (Zahlenlisten, die Bedeutung repräsentieren), der die einer Abfrage ähnlichsten Elemente findet, meist mit Indizes für die approximative Nächste-Nachbarn-Suche. Kapitel 7
Verantwortlicher: Die Organisation, die über die Zwecke und Mittel der Verarbeitung personenbezogener Daten entscheidet und die Hauptverantwortung für die Einhaltung des Datenschutzrechts trägt. Kapitel 8
Verfügbarkeit: Der Anteil der Zeit oder der Anfragen, in dem ein System bereit ist, seinen Dienst auf Anforderung zu erbringen, meist als Prozentsatz angegeben, etwa 99,9 %. Kapitel 2
Verhaltensbasierte Subtypisierung: Die Regel hinter der Liskovschen Substitution: Ein Subtyp darf von Aufrufern nicht mehr verlangen (stärkere Vorbedingungen), nicht weniger versprechen (schwächere Nachbedingungen) und die Invarianten des Supertyps nicht verletzen. Kapitel 3
Verletzung des Schutzes personenbezogener Daten: Nach Artikel 4 Nr. 12 DSGVO eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust oder zur Veränderung, ob unbeabsichtigt oder unrechtmäßig, oder zur unbefugten Offenlegung von beziehungsweise zum unbefugten Zugang zu personenbezogenen Daten führt. Kapitel 8
Versionskontrolle: Ein System, das jede Änderung an einer Menge von Dateien aufzeichnet, wer sie vorgenommen hat und warum, sodass Menschen parallel arbeiten, Änderungen prüfen und zu jeder früheren Version zurückkehren können. Kapitel 0
Verteilte Architektur: Eine Architektur aus mehreren separat deployten Einheiten, die zusammenarbeiten, indem sie Nachrichten über ein Netzwerk senden. Kapitel 5
Verteilter Monolith: Ein als separate Services deploytes System, deren Kopplung so eng ist, dass sie gemeinsam geändert und ausgeliefert werden müssen; es hat die Kosten der Verteilung ohne ihre Vorteile. Kapitel 5
Verteiltes System: Eine Menge von Programmen auf verschiedenen Computern, die zusammenarbeiten, indem sie Nachrichten über ein Netzwerk senden, sodass Benutzer einen einzigen Dienst sehen. Kapitel 6
Vertikale Skalierung (Scale-up): Mehr Last bewältigen, indem auf eine größere Maschine mit mehr Prozessoren oder Arbeitsspeicher gewechselt wird. Kapitel 0
Vertrauensgrenze: Eine Linie in einem System, an der Daten oder Kontrolle zwischen Teilen mit unterschiedlichem Vertrauens- oder Berechtigungsniveau wechseln, etwa vom Internet in eine API, sodass Eingaben dort geprüft werden müssen. Kapitel 8
Virtuelle Maschine (VM): Eine softwarebasierte Nachbildung eines vollständigen Computers mit eigenem Betriebssystem, die neben anderen VMs auf einer physischen Maschine unter einem Hypervisor läuft. Kapitel 0
Virtueller Benutzer: Ein simulierter Benutzer in einem Lasttestwerkzeug, der ein Skript von Anfragen ausführt, meist in einer Schleife. Kapitel 9
Vorbedingung: Eine Bedingung, die vor dem Aufruf einer Operation erfüllt sein muss; sie zu erfüllen ist Pflicht des Aufrufers. Kapitel 3

W

Walking Skeleton: Eine winzige Implementierung des Systems, die eine kleine End-to-End-Funktion über alle wichtigen Architekturkomponenten hinweg ausführt und meist zuerst gebaut wird. Kapitel 1
Warm Standby: Eine Disaster-Recovery-Strategie, die eine verkleinerte, aber voll funktionsfähige Kopie des Systems in einer zweiten Region laufen lässt, bereit, Datenverkehr zu übernehmen und hochzuskalieren. Kapitel 10
Wartbarkeit: In ISO/IEC 25010, wie wirksam und effizient sich ein Produkt ändern lässt, mit den Teilmerkmalen Modularität, Wiederverwendbarkeit, Analysierbarkeit, Änderbarkeit und Testbarkeit. Kapitel 2
Warteschlangenbildung (Queueing): Das Warten auf eine ausgelastete Ressource. Die Warteschlangentheorie untersucht, wie die Wartezeit mit der Auslastung wächst; sie erklärt, warum die Antwortzeit steil ansteigt, wenn eine Ressource sich 100 % Auslastung nähert. Kapitel 2
Watermark: Die fortlaufende Schätzung eines Stream-Prozessors, dass alle Ereignisse bis zu einer bestimmten Ereigniszeit wahrscheinlich eingetroffen sind, anhand derer entschieden wird, wann das Ergebnis eines Fensters ausgegeben werden kann. Kapitel 7
WCAG: Die Web Content Accessibility Guidelines des W3C. Version 2.2 (2023) legt prüfbare Erfolgskriterien auf den Stufen A, AA und AAA fest; Stufe AA ist der übliche rechtliche Maßstab. Kapitel 2
Web-API: Eine über ein Netzwerk angebotene API, meist über HTTP, damit Programme auf verschiedenen Maschinen, geschrieben in verschiedenen Sprachen, zusammenarbeiten können. Kapitel 0
Webhook: Eine HTTP-Anfrage, die ein Anbieter an eine von seinem Kunden registrierte URL sendet, wenn ein Ereignis eintritt, etwa eine erfolgreiche Zahlung. Sie kehrt die übliche Richtung eines API-Aufrufs um. Kapitel 0
Wechselkosten (Switching Cost): Der gesamte Aufwand, das Geld und das Risiko, die nötig sind, um von einer Technologie oder einem Anbieter zu einem anderen zu wechseln. Kapitel 10
Wide-Column-Store: Eine NoSQL-Datenbank, die Daten in über einen Schlüssel identifizierte Zeilen mit jeweils vielen Spalten gruppiert, verteilt auf viele Maschinen. Ausgelegt für sehr große Schreibvolumen. Kapitel 0
Wissenspyramide: Ein Modell mit drei Ebenen: was Sie wissen, wovon Sie wissen, dass Sie es nicht wissen, und wovon Sie nicht wissen, dass Sie es nicht wissen. Architekten erweitern gezielt die mittlere Ebene. Kapitel 1
Workload Identity: Eine überprüfbare Identität für einen laufenden Service statt für eine Person, ausgestellt von der Plattform (zum Beispiel eine SPIFFE-ID in einem kurzlebigen Zertifikat), die statt gemeinsamer Geheimnisse verwendet wird. Kapitel 8
Write Skew: Eine Anomalie, bei der zwei Transaktionen sich überschneidende Daten lesen, jede eine Änderung für sicher hält und sie verschiedene Zeilen aktualisieren, wodurch sie gemeinsam eine Regel verletzen, die jede einzeln geprüft hat. Kapitel 7
Write-Ahead-Log (WAL): Ein Log auf der Festplatte, an das nur angehängt wird und in dem eine Datenbank jede Änderung vor ihrer Anwendung festhält, sodass bestätigte Arbeit einen Absturz übersteht; Replikate werden oft daraus gespeist. Kapitel 7
Write-behind-Cache: Ein Caching-Muster, bei dem Schreibvorgänge bestätigt werden, sobald sie den Cache erreichen, und erst später im Hintergrund in den darunterliegenden Speicher geschrieben werden; auch Write-back genannt. Kapitel 7
Write-through-Cache: Ein Caching-Muster, bei dem jeder Schreibvorgang in den Cache und in den darunterliegenden Speicher gelangt, bevor er bestätigt wird, sodass der Cache nie älter ist als der Speicher. Kapitel 7

X

X-as-a-Service: Ein Interaktionsmodus, bei dem ein Team etwas nutzt, das ein anderes Team bereitstellt, über eine klare, dokumentierte Schnittstelle und mit wenig alltäglicher Zusammenarbeit. Kapitel 11
XA: Die X/Open-Standardschnittstelle (1991) zwischen einem Transaktionsmanager und Ressourcenmanagern wie Datenbanken und Message Brokern, mit der ein Two-Phase Commit über sie hinweg ausgeführt wird. Kapitel 6

Y

Y-Statement: Ein Entscheidungsprotokoll in einem Satz von Olaf Zimmermann: Im Kontext von …, angesichts …, haben wir uns entschieden für … und gegen …, um … zu erreichen, und nehmen in Kauf, dass …. Kapitel 4
YAGNI: You aren’t gonna need it: eine Praxis aus Extreme Programming, keine Fähigkeiten für nur vermutete Bedürfnisse zu bauen, weil sie jetzt Aufwand und später Komplexität kosten. Kapitel 3

Z

Zeichenwerkzeug: Ein Diagrammwerkzeug, das nur Formen, Linien und Text kennt, sodass dasselbe Element, in zwei Diagrammen gezeichnet, keine Verbindung zwischen ihnen hat. Kapitel 4
Zeitliche Kopplung: In verteilten Systemen die Abhängigkeit davon, dass ein anderer Teil im selben Moment verfügbar ist und antwortet, wie bei einem synchronen Aufruf. Anderswo kann der Begriff eine vorgeschriebene Reihenfolge von Aufrufen bezeichnen oder (bei der Analyse der Versionskontrolle) Dateien, die sich gemeinsam ändern, was dieses Kapitel Change Coupling nennt. Kapitel 3
Zeitreihendatenbank: Eine Datenbank, optimiert für zeitgestempelte Messwerte, die der Reihe nach eintreffen, mit Komprimierung, Downsampling und kostengünstigem Löschen alter Daten. Kapitel 7
Zellbasierte Architektur: Der Betrieb vieler vollständiger, unabhängiger Kopien (Zellen) eines Systems hinter einem schlanken Router, von denen jede eine feste Teilmenge der Kunden bedient, sodass ein Ausfall nur eine Zelle betrifft. Kapitel 10
Zerlegung: Das Aufteilen eines Systems in Teile (Module) und die Festlegung, wofür jeder Teil zuständig ist. Das Kriterium der Aufteilung ist wichtiger als die Zahl der Teile. Kapitel 3
Zero Trust: Ein Sicherheitsmodell, das kein implizites Vertrauen aufgrund des Netzwerkstandorts gewährt: Jede Anfrage wird pro Ressource und pro Sitzung authentifiziert, autorisiert und verschlüsselt (NIST SP 800-207). Kapitel 8
Zertifizierungsstelle (CA): Eine Organisation oder ein System, das digitale Zertifikate durch Signieren ausstellt und damit bestätigt, dass ein öffentlicher Schlüssel zu einem benannten Server, einer Person oder einem Workload gehört. Kapitel 8
Zinsen (technischer Schulden): Der zusätzliche Aufwand, die Verzögerung oder das Risiko, die bei jeder Änderung anfallen, weil die Schulden nicht getilgt wurden. Kapitel 1
Zuordnungssicht: Eine Sicht, die Software auf Dinge außerhalb von ihr abbildet: Infrastruktur (Deployment), Dateien und Builds (Implementierung) oder Teams (Arbeitszuteilung). Kapitel 4
Zustandsdiagramm: Ein UML-Diagramm, das die Zustände zeigt, in denen sich ein Objekt befinden kann, und die Übergänge zwischen ihnen, die jeweils durch ein Ereignis ausgelöst werden. Kapitel 4
Zustandslose Anwendung (Stateless): Eine Anwendung, die zwischen Anfragen keine benutzerbezogenen Daten im eigenen Speicher hält, sodass jede Kopie jede Anfrage bearbeiten kann und Kopien beliebig hinzugefügt oder entfernt werden können. Kapitel 5
Zustandsloser Service: Eine Service-Instanz, die zwischen Anfragen keine Daten in ihrem eigenen Speicher oder auf ihrer Festplatte hält, sodass jede Instanz jede Anfrage bearbeiten kann und Instanzen beliebig hinzugefügt oder entfernt werden können. Kapitel 9
Zuverlässigkeit: Die Wahrscheinlichkeit, dass ein System für einen festgelegten Zeitraum unter festgelegten Bedingungen korrekt und ohne Ausfall arbeitet. Ein System kann hochverfügbar und dennoch unzuverlässig sein, wenn es oft ausfällt, sich aber schnell erholt. Kapitel 2
Zyklomatische Komplexität: Das 1976 von Thomas McCabe eingeführte Maß für die Zahl unabhängiger Pfade durch ein Stück Code, berechnet aus seinem Kontrollflussgraphen; bei einfachem Code entspricht es der Zahl der Entscheidungen plus eins. Kapitel 3