Glossar

Nachschlagewerk wichtiger Begriffe aus der Skalierbarkeits-Serie.

A

ACID

Akronym für Atomicity, Consistency, Isolation, Durability — die vier Garantien relationaler Datenbanktransaktionen. Isolation erzwingt die Serialisierung gleichzeitiger Schreibzugriffe und ist damit eine der Hauptursachen für Lock Contention unter Last.

Siehe auch:

Amdahl’s Law

Beschreibt die theoretische Obergrenze der Beschleunigung durch Parallelisierung. Der serielle Anteil eines Prozesses begrenzt den maximal möglichen Speedup — bei 10% seriellem Anteil liegt das Maximum bei 10x, egal wie viele parallele Einheiten hinzugefügt werden. Gilt für Hardware, verteilte Systeme und Organisationen gleichermaßen.

Siehe auch:

  • Amdahl (1967) — Validity of the single processor approach. AFIPS Spring Joint Computer Conference Proceedings, Vol. 30.

Antwortzeit

Die gesamte Zeit vom Absenden eines Requests bis zum Empfang der Antwort — in Formeln als W notiert. Enthält Servicezeit, Wartezeit im Pool, Datenbankzugriffe und externe Aufrufe. In der Serie wird konsequent “Antwortzeit” statt “Response Time” oder “Latenz” verwendet.

Siehe auch:

Auslastung

Der Anteil der genutzten Kapazität eines Systems — in Formeln als ρ (Rho) notiert. Bei 70% Auslastung läuft ein System typischerweise stabil; ab 80–90% explodieren die Wartezeiten nichtlinear.

Siehe auch:

Autoscaling

Automatisches Hinzufügen oder Entfernen von Instanzen basierend auf der aktuellen Last. Überbrückt die Lücke zwischen “Implement” und “Deploy” im DID-Prinzip. Ohne obere Limits können die Kosten unkontrolliert wachsen.

Siehe auch:

B

Backpressure

Mechanismus, bei dem eine überlastete Komponente dem Aufrufer signalisiert, langsamer zu senden. Die operative Antwort auf exponentielles Warteschlangenwachstum nahe der Sättigung.

Siehe auch:

Brooks’ Law

“Adding manpower to a late software project makes it later.” Der Kommunikationsaufwand zwischen n Personen wächst mit n×(n-1)/2 — quadratisch. Das ist die organisatorische Entsprechung des USL: Mehr Leute erzeugen mehr Koordinationsoverhead, der den Produktivitätsgewinn auffrisst.

Siehe auch:

Bulkhead Pattern

Isoliert Ressourcen (Thread-Pools, Connections) pro Consumer oder Service, sodass eine überlastete Komponente nicht alle anderen mitreißt. Benannt nach den Schotten eines Schiffs.

Siehe auch:

C

CAP-Theorem

Bei Netzwerkpartitionen muss ein verteiltes System zwischen Consistency und Availability wählen — beides gleichzeitig ist nicht möglich. Partitionstoleranz ist keine Option, weil Netzwerke partitioniert werden. Wird durch PACELC erweitert.

Siehe auch:

  • Brewer (2000) — Towards Robust Distributed Systems. ACM PODC Keynote.

Circuit Breaker

Schutzmechanismus für Remote-Aufrufe: Nach mehreren Fehlern in Folge öffnet der Circuit Breaker und lässt Aufrufe sofort scheitern, statt auf Timeouts zu warten. Verhindert kaskadierende Ausfälle in Microservice-Architekturen.

Siehe auch:

Compound Failure Probability

Jeder Service in einer synchronen Aufrufkette reduziert die Gesamtverfügbarkeit multiplikativ: 5 Services mit je 99,9% Verfügbarkeit ergeben 99,5% — nicht 99,9%. Das quantitative Argument für asynchrone Integration und gröbere Schnitte (SCS statt feinkörniger Microservices).

Siehe auch:

Concurrency

Die mittlere Anzahl an Anfragen, die sich gleichzeitig im System befinden — in Formeln als L notiert. Steigt dieser Wert über die Pool-Größe, beginnen Requests zu warten.

Siehe auch:

Connection-Pool

Ein Pool vorab aufgebauter Datenbankverbindungen, die von Threads gemeinsam genutzt werden. Die Pool-Größe ist oft der erste Engpass unter Last — ein zu kleiner Pool (wie der Framework-Default von 10) kann einen Service bei moderatem Traffic zum Zusammenbruch bringen.

Siehe auch:

Connection Pool Exhaustion

Zustand, in dem alle Datenbankverbindungen im Pool belegt sind. Threads blockieren auf freie Verbindungen, halten dabei ihren Thread-Pool-Platz besetzt, und das System kollabiert kaskadierend. Little’s Law berechnet die exakte Grenze.

Siehe auch:

Conway’s Law

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” Teamstruktur und Systemstruktur sind isomorph. Das “Inverse Conway Maneuver” dreht die Kausalität um: zuerst die Teamstruktur optimieren, dann folgt die Architektur.

Siehe auch:

CQRS

Command Query Responsibility Segregation — Trennung von Schreib- und Lesemodell. Das Query-Modell wird für schnellen Zugriff optimiert (z.B. Elasticsearch, materialisierte Views), während das Command-Modell für Konsistenz sorgt. Häufig in Kombination mit Event Sourcing und asynchroner Integration.

Siehe auch:

D

DORA (DevOps Research and Assessment)

Forschungsprogramm, das Software-Delivery-Performance empirisch misst. Vier Kernmetriken: Deployment Frequency, Lead Time for Changes, Mean Time to Recovery, Change Failure Rate. Elite-Teams deployen mehrmals täglich mit unter einer Stunde Recovery. Die Forschung zeigt: Branche und Unternehmensgröße sagen Performance nicht voraus — Architektur, Teamstruktur und Kultur schon. Das 2024-Finding zu AI-Coding-Assistenten (-7,2% Stability durch größere Batches) bestätigt Reinertsens Batch-Size-Theorie empirisch.

Siehe auch:

DID-Prinzip

Design–Implement–Deploy: Design für 20x den aktuellen Bedarf, Implement für 3–20x, Deploy für 1,5–3x. Die Trennung reflektiert die asymmetrischen Änderungskosten — eine nachträgliche Architekturänderung ist um Größenordnungen teurer als eine Deployment-Anpassung. Der wirtschaftliche Anker der gesamten Serie.

Siehe auch:

Diseconomies of Scale

Software hat negative Skaleneffekte: Größere Teams produzieren weniger Output pro Person. Das Gegenteil von Manufacturing, wo doppelte Kapazität weniger als doppelte Kosten verursacht. Der ökonomische Kern des Arguments für kleine, autonome Teams.

Siehe auch:

Durchsatz

Die mittlere Anzahl der Anfragen, die pro Sekunde fertig bearbeitet werden — in Formeln als λ (Lambda) notiert. Beschreibt, was tatsächlich durchkommt, nicht was angefragt wird. In der Serie wird konsequent “Durchsatz” statt “Throughput” verwendet.

Siehe auch:

E

Engpass

Die Komponente, die den Durchsatz des Gesamtsystems begrenzt. In den meisten Web-Anwendungen ist das die Datenbank. In der Serie wird konsequent “Engpass” statt “Bottleneck” verwendet.

Siehe auch:

Eventual Consistency

Ein Konsistenzmodell, bei dem Leseoperationen nicht sofort den aktuellsten Schreibwert sehen — aber das System konvergiert innerhalb eines kurzen Zeitfensters. Der unvermeidliche Preis für Datenpartitionierung und asynchrone Integration.

Siehe auch:

Event Sourcing

Speichert Zustandsänderungen als append-only Sequenz unveränderlicher Events statt als veränderbare Datensätze. Eliminiert Write-Contention, weil Anhängen an ein Log keine Locks erfordert.

Siehe auch:

F

Funktionale Dekomposition

Zerlegung eines Systems entlang fachlicher Grenzen — vertikale Schnitte nach Domäne, nicht horizontale Schichten nach Technologie. Jedes Vertikal bildet eine vollständige Business Capability ab. Die Grundidee hinter der Y-Achse des Scale Cube.

Siehe auch:

G

Goodhart’s Law

“When a measure becomes a target, it ceases to be a good measure.” Direkt relevant für Governance bei skalierter Organisation: Wenn Metriken (Deployment-Frequenz, Velocity) zum Steuerungsinstrument werden, optimieren Teams auf die Metrik statt auf das Ergebnis.

Siehe auch:

Graceful Degradation

Statt komplettem Ausfall reduziert das System die Funktionalität — gecachte Daten, deaktivierte Empfehlungen, statische Fallbacks. Das Sicherheitsnetz, wenn Autoscaling oder Circuit Breaker nicht ausreichen.

Siehe auch:

Gustafson’s Law

Gegenperspektive zu Amdahl’s Law: Bei wachsender Problemgröße ist nahezu linearer Speedup möglich, solange der serielle Anteil absolut konstant bleibt. Gilt für HPC-Workloads, bricht aber für Organisationen zusammen, weil der Kommunikationsoverhead quadratisch wächst.

Siehe auch:

H

High Cohesion

Alles, was zusammengehört, ist zusammen — keine Verantwortung über mehrere Module oder Teams verstreut. Auf Teamebene: ein Team, eine fachliche Domäne, volle Produktverantwortung. Das Gegenstück zu Loose Coupling.

Siehe auch:

Hockeyschläger-Kurve

Die charakteristische Form des Antwortzeit-Verlaufs unter steigender Last: lange flach, dann steil ansteigend. Entsteht durch den nichtlinearen Auslastungsfaktor ρ/(1-ρ) in Kingman’s Formula. Die Variabilität der Servicezeiten bestimmt, wie steil die Kurve wird.

Siehe auch:

K

Kingman’s Formula

Näherung für die Wartezeit in einer Warteschlange mit variablen Servicezeiten: Wartezeit ≈ V × ρ/(1-ρ) × S. Drei Faktoren — Variabilität (V), Auslastungsfaktor und Servicezeit (S) — erklären, warum Systeme schon weit vor der theoretischen Kapazitätsgrenze einbrechen.

Siehe auch:

Kanban

Methode zur Steuerung von Arbeitsprozessen, die auf expliziten WIP-Limits basiert. David Anderson hat 2010 gezeigt, wie Little’s Law das Fundament liefert: Lead Time = WIP / Durchsatz. Daraus folgt direkt: Wer die Lead Time senken will, muss WIP begrenzen — nicht den Durchsatz erhöhen. Kanban-Boards machen WIP sichtbar; die Limits erzwingen, dass neues erst begonnen wird, wenn laufendes abgeschlossen ist.

Siehe auch:

L

Lead Time

Die Gesamtzeit vom Eingang einer Aufgabe bis zu ihrer Auslieferung — das organisatorische Pendant zur Antwortzeit (W) in Little’s Law. Enthält Wartezeit und Bearbeitungszeit. Little’s Law gilt direkt: Lead Time = WIP / Durchsatz. Kingman erklärt, warum Lead Time bei hoher Auslastung überproportional steigt — nicht weil die Bearbeitung langsamer wird, sondern weil die Wartezeit explodiert.

Siehe auch:

Lasttest

Empirische Überprüfung der Kapazitätsgrenzen eines Systems unter simulierter Last. Little’s Law sagt, wo man anfangen soll — der Lasttest zeigt, was in der Praxis passiert. Abweichungen zwischen Berechnung und Messung sind ein Signal für versteckte Abhängigkeiten.

Siehe auch:

Long Tail

Die große Menge seltener Anfragen, die einzeln kaum ins Gewicht fallen, in Summe aber einen erheblichen Anteil des Traffics ausmachen. Zipf’s Law erklärt das Muster: Wenige Items dominieren, der Rest verteilt sich auf eine riesige Vielfalt. Long-Tail-Anfragen sind nicht cachebar und erzeugen hohe Variabilität — mit den Konsequenzen, die Kingman’s Formula vorhersagt.

Siehe auch:

Lehman’s Laws

Empirisch belegte Gesetze der Softwareentwicklung. Besonders relevant: Law II (Increasing Complexity) — die Komplexität eines Systems wächst überproportional, wenn nicht aktiv gegengesteuert wird. Gibt dem Argument für funktionale Dekomposition formale Rückendeckung.

Siehe auch:

Little’s Law

L = λ × W — die Anzahl gleichzeitiger Anfragen im System (L) entspricht dem Durchsatz (λ) multipliziert mit der Antwortzeit (W). Gilt für jedes stabile Wartesystem, unabhängig von der Verteilung der Ankünfte. Das Fundament der Kapazitätsplanung in dieser Serie.

Siehe auch:

Load Balancer

Verteilt eingehende Requests auf mehrere Instanzen eines Service. Strategien: Round-Robin, Least-Connection, Sticky Sessions (wobei letztere Stateless Design untergraben). Voraussetzung für X-Achsen-Skalierung.

Siehe auch:

Load Shedding

Bewusstes Verwerfen niedrigpriorer Requests unter Überlast, um Kapazität für kritische Funktionen zu erhalten. Anders als Rate Limiting triagiert Load Shedding nach Priorität.

Siehe auch:

Lock Contention

Gleichzeitige Schreibzugriffe auf dieselben Datensätze müssen serialisiert werden — die resultierenden Wartezeiten auf Locks wachsen nichtlinear mit der Last. Lock Contention ist der prototypische “serielle Anteil” im Sinne von Amdahl’s Law.

Siehe auch:

Loose Coupling

Minimale Abhängigkeiten zwischen Modulen, Services oder Teams. Ein Modul kann geändert werden, ohne andere zu brechen. Die technische Antwort auf Amdahl’s Diagnose: Wer den seriellen Anteil gegen null treibt, erreicht nahezu lineare Skalierbarkeit.

Siehe auch:

M

Metcalfe’s Law

Die Anzahl möglicher Kommunikationskanäle in einem Netzwerk mit N Knoten wächst mit N×(N-1)/2 — quadratisch. Die Formel hinter Brooks’ Law und dem κ-Term des USL. Bei 5 Teams gibt es 10 Kanäle, bei 10 Teams 45, bei 50 Teams 1.225.

Siehe auch:

Microservices

Kleine, unabhängig deploybare Services mit eigener Datenhaltung und klar definierten APIs. Feiner geschnitten als SCS, ohne eigenes Frontend. Der operative Overhead ist höher — zu frühes Zerschneiden ist teuer.

Siehe auch:

N

N+1-Query-Problem

Code-Antipattern, bei dem für eine Liste von N Objekten N+1 Datenbankzugriffe ausgeführt werden statt eines JOINs oder einer IN-Klausel. Bei 50 Bestellungen: 51 Queries statt 2. Unter Last multipliziert sich dieser Overhead mit der Anzahl gleichzeitiger Requests.

Siehe auch:

NoSQL

Datenbanksysteme, die auf ACID-Garantien und JOIN-Fähigkeit zugunsten natürlicher Partitionierbarkeit verzichten. Im Kern Z-Achsen-Datenbanken: Cassandra, DynamoDB, MongoDB nutzen Partition Keys als Sharding-Mechanismus. Der Preis ist fast immer Eventual Consistency.

Siehe auch:

P

PACELC

Erweiterung des CAP-Theorems: Auch ohne Netzwerkpartition muss zwischen Latency und Consistency gewählt werden. Dieser Trade-off gilt immer, nicht nur im Fehlerfall — und ist damit der schärfere Kompromiss. Beispiel: Cassandra wählt Verfügbarkeit und niedrige Latenz (PA/EL), HBase wählt Konsistenz (PC/EC).

Siehe auch:

Perzentil

Beschreibt die Grenze, unter der ein bestimmter Anteil aller Messwerte liegt. p95 = 250 ms heißt: 95% der Anfragen sind schneller, aber jede zwanzigste braucht länger. Die höheren Perzentile sind die wichtigeren Monitoring-Werte, weil sie — anders als der Mittelwert — sichtbar machen, was die langsamsten Nutzer erleben.

Siehe auch:

Q

Queue

Warteschlange, in der Requests stehen, bis eine Ressource (Thread, Connection, CPU) frei wird. Die Queue-Länge wächst nichtlinear mit der Auslastung — das zentrale Thema der Warteschlangentheorie in dieser Serie.

Siehe auch:

R

Rate Limiting

Begrenzung der Request-Frequenz pro Client oder API. Token Bucket erlaubt Bursts, Leaky Bucket erzwingt gleichmäßigen Durchsatz. Schützt den Service vor Überlast, unterscheidet aber — anders als Load Shedding — nicht nach Priorität.

Siehe auch:

Read Replica

Replizierte Datenbankkopie, die Lesezugriffe bedient, während der primäre Knoten Schreibzugriffe verarbeitet. Die einfachste Form der Leseentlastung — zum Preis eines Replikations-Lags (Eventual Consistency).

Siehe auch:

S

Sättigungspunkt

Der Punkt, ab dem die Antwortzeiten eines Systems überproportional steigen — typischerweise bei 70–80% Auslastung, nicht erst bei 100%. In dieser Serie wird konsequent “Sättigungspunkt” statt “Knie der Kurve” verwendet, weil der Begriff die Ursache enthält.

Siehe auch:

Scale Cube

Modell von Abbott & Fisher mit drei Dimensionen der Skalierung: X-Achse (Duplizierung), Y-Achse (funktionale Dekomposition) und Z-Achse (Datenpartitionierung). Die meisten Systeme, die ernsthaft skalieren, kombinieren mindestens zwei Achsen.

Siehe auch:

Scale-Up

Vertikale Skalierung durch eine größere Maschine — mehr CPU, mehr RAM, schnellere Storage. Funktioniert kurzfristig, aber die Kosten wachsen überproportional und es gibt eine harte physikalische Obergrenze. Für Datenbanken oft der pragmatische erste Schritt.

Siehe auch:

SCS (Self-Contained System)

Eigenständige Web-Anwendung mit eigenem Frontend, eigener Datenbank und eigenem Deployment-Zyklus. Gröber geschnitten als Microservices und mit weniger synchronen Abhängigkeiten. Jedes SCS kann seine primären Use Cases erfüllen, ohne dass andere Systeme verfügbar sein müssen.

Siehe auch:

Serieller Anteil

  • In Amdahl’s Law: der Anteil eines Prozesses, der nicht parallel ausgeführt werden kann.
  • In verteilten Systemen: jede geteilte Ressource (Datenbank, Message Broker, Deployment-Pipeline, Mensch). Bestimmt die theoretische Obergrenze der Skalierbarkeit.

Siehe auch:

Servicezeit

Die reine Verarbeitungszeit einer Anfrage — ohne Wartezeit in der Queue. In Kingman’s Formula als S notiert. Jede Millisekunde Einsparung bei der Servicezeit wirkt doppelt: einmal direkt und einmal multiplikativ über die reduzierte Wartezeit.

Siehe auch:

Sharding

Horizontale Partitionierung von Daten nach einem Sharding-Schlüssel (z.B. Kunden-ID, Region). Die Z-Achse des Scale Cube auf der Datenschicht. Die Wahl des Schlüssels bestimmt die Qualität der Verteilung — schlechte Schlüssel erzeugen Hot Spots.

Siehe auch:

Shared-Nothing

Architekturprinzip, bei dem Instanzen, Services oder Teams keine Ressourcen teilen — keine gemeinsame Datenbank, kein geteilter Cache, kein geteilter Code. Voraussetzung für lineare Skalierung. Gilt auf technischer Ebene (Service-Architektur) wie auf organisatorischer Ebene (Teamstruktur).

Siehe auch:

Slack Time

Bewusst freigehaltene Kapazität — die organisatorische Entsprechung von Kapazitätspuffern in Thread-Pools oder Connection-Pools. Kingman liefert die mathematische Begründung: Der Unterschied zwischen 80% und 95% Auslastung ist nicht 15 Prozentpunkte, sondern ein Faktor 3–4 in der Wartezeit. Slack Time ist kein Leerlauf — sie ist die Investition in stabile Durchlaufzeiten und die Fähigkeit, auf Unerwartetes zu reagieren.

Siehe auch:

Skalierbarkeit

Die Fähigkeit eines Systems, Leistung proportional zu den eingesetzten Ressourcen zu steigern. Nicht gleichbedeutend mit Performance — ein System kann schnell sein und trotzdem nicht skalieren, wenn zusätzliche Ressourcen keinen proportionalen Gewinn bringen.

Siehe auch:

Stateless Design

Architekturprinzip, bei dem Applikationsinstanzen keinen Zustand halten — alle Zustände liegen extern (Datenbank, Cache, Cookies). Voraussetzung für X-Achsen-Skalierung, weil jede Instanz austauschbar wird.

Siehe auch:

T

Team Topologies

Modell von Skelton & Pais mit vier Teamtypen: Stream-Aligned Teams, Platform Teams, Enabling Teams und Complicated-Subsystem Teams. Platform Teams stellen Werkzeuge und Infrastruktur bereit; Enabling Teams vermitteln Know-how — beide ohne Abhängigkeiten zu schaffen.

Siehe auch:

Team-of-Teams

Organisationsmodell nach McChrystal: Lose gekoppelte Gruppen von Teams mit hoher interner Kohäsion und definierten Schnittstellen nach außen. Bricht die quadratische Kommunikationstopologie in eine hierarchische — innerhalb einer Gruppe direkte Kommunikation, zwischen Gruppen nur über definierte Schnittstellen.

Siehe auch:

Theory of Constraints

Jedes System hat genau einen Engpass, der den Durchsatz begrenzt. Alles andere zu optimieren ist Verschwendung. Die Five Focusing Steps — Identify, Exploit, Subordinate, Elevate, Repeat — geben eine Methode statt nur einer Beobachtung.

Siehe auch:

Thread-Pool

Ein Pool vorab erstellter Threads, die eingehende Requests bearbeiten. Die meiste Zeit sind Threads blockiert und warten auf I/O — “Thread-Wartezimmer” wäre der ehrlichere Name. Little’s Law dimensioniert die Pool-Größe: maximaler Durchsatz = Pool-Größe / Antwortzeit.

Siehe auch:

U

USL (Universal Scalability Law)

Erweiterung von Amdahl’s Law um einen Kohärenz-Parameter κ (Crosstalk): C(n) = n / (1 + σ(n-1) + κ×n×(n-1)). Der κ-Term wächst quadratisch — ab einem bestimmten Punkt sinkt der Durchsatz, statt nur zu stagnieren. Erklärt retrograde Skalierung bei Datenbank-Lock Contention und bei Organisationen (Brooks’ Law).

Siehe auch:

V

Variabilität

Ein Maß dafür, wie stark die Servicezeiten um ihren Mittelwert streuen — in Kingman’s Formula als V notiert. V = 0 bedeutet konstante Zeiten (keine Warteschlange), V = 1 exponentiell verteilte Zeiten (Worst Case). Die Mischung aus Cache-Hits und teuren Queries erzeugt hohe Variabilität — und damit Phantomstaus.

Siehe auch:

Virtual Threads

Seit Java 21 verfügbar: Leichtgewichtige Threads, die die Verarbeitungskapazität von der Anzahl blockierter OS-Threads entkoppeln. Ändert den Optimierungsansatz für Thread-Pools, aber nicht die Grundaussage von Little’s Law — und nichts am Connection-Pool als Engpass.

Siehe auch:

W

Warteschlangentheorie

Mathematische Disziplin, die das Verhalten von Wartesystemen beschreibt. Little’s Law und Kingman’s Formula sind die beiden zentralen Werkzeuge dieser Serie. Die Kernaussage: Systeme nahe der Sättigung verhalten sich fundamental anders als Systeme unter moderater Last.

Siehe auch:

WIP (Work in Progress)

Die Anzahl gleichzeitig begonnener, aber nicht abgeschlossener Aufgaben — das organisatorische Pendant zur Concurrency (L) in Little’s Law. Teams füllen Wartezeiten mit neuen Projekten, WIP steigt, Auslastung steigt, Wartezeiten explodieren — ein Teufelskreis. “Stop Starting, Start Finishing” bricht den Kreislauf.

Siehe auch:

X

X-Achse

Erste Dimension des Scale Cube: Duplizierung. Mehrere identische Instanzen hinter einem Load Balancer. Setzt Stateless Design voraus und skaliert linear — solange keine geteilte Ressource zum Engpass wird.

Siehe auch:

Y

Y-Achse

Zweite Dimension des Scale Cube: Funktionale Dekomposition. Zerlegung eines Systems in unabhängige Services entlang fachlicher Grenzen — jeder mit eigener Datenhaltung, eigenem Deployment, eigener Teamverantwortung. Die sauberste Übertragung auf Organisationsebene (Conway’s Law).

Siehe auch:

You Build It, You Run It

Prinzip, dass das Team, das einen Service entwickelt, ihn auch betreibt. Eliminiert die Abhängigkeit zwischen Dev und Ops und verkürzt Feedback-Loops. Erfordert organisatorische Investition in Tooling, On-Call-Support und kulturellen Wandel.

Siehe auch:

Z

Z-Achse

Dritte Dimension des Scale Cube: Datenpartitionierung (Sharding). Requests oder Daten werden nach einem Schlüssel (Kunden-ID, Region) auf verschiedene Partitionen verteilt. Auf der Datenschicht gut etabliert (NoSQL), auf der App-Schicht selten — weil Z-Achse stateful Routing erfordert, was Stateless Design (Voraussetzung für X-Achse) widerspricht.

Siehe auch:

Zipf’s Law

Die Häufigkeit des k-populärsten Items ist proportional zu 1/k^α — wenige Items dominieren, die meisten sind selten. Erklärt, warum Caching so spektakulär gut funktioniert (die Top-1% erzeugen 80% des Traffics) und warum es irgendwann nicht mehr reicht: Der Long Tail wächst mit dem Traffic.

Siehe auch: