Tragedy of the Commons

Beschreibung

Die "Tragödie der Allmende" (Tragedy of the Commons) beschreibt eine Situation, in der mehrere Akteure eine gemeinsame Ressource nutzen, ohne dass Verbrauch, Kosten und Verantwortung ausreichend geregelt sind. Für jedes einzelne Team kann es kurzfristig sinnvoll wirken, die Ressource stärker zu nutzen: mehr Builds, mehr Logs, mehr Daten, mehr Plattformkapazität. Wenn alle Teams so handeln, wird die gemeinsame Ressource überlastet. Das Problem entsteht nicht zwingend aus böser Absicht, sondern aus lokal rationalen Entscheidungen in einer unzureichend gestalteten Governance-Struktur.

Feedback Loops

Jeder Akteur besitzt eine lokale verstärkende Schleife: Mehr Nutzung der gemeinsamen Ressource ermöglicht mehr eigene Ergebnisse. Die Kosten dieser Nutzung werden jedoch nicht direkt beim verursachenden Team sichtbar, sondern im gemeinsamen System gesammelt. Dort entsteht mit Verzögerung eine ausgleichende Schleife: Performance sinkt, Wartung steigt, Ausfälle nehmen zu oder Governance muss nachträglich eingreifen. Dadurch werden am Ende auch Teams belastet, die sich individuell nachvollziehbar verhalten haben.

Architekturbeispiel

Ein zentrales Elasticsearch-Cluster wird ohne Quotas, Retention-Regeln oder Kostenverrechnung bereitgestellt. Team A speichert große JSON-Payloads, weil es für die eigene Analyse bequem ist. Team B legt umfangreiche Debug-Logs ab, weil dafür keine direkten Kosten sichtbar werden. Mit der Zeit steigen Speicherbedarf, Indexgröße und Abfragekosten. Das Cluster wird langsamer oder fällt aus, obwohl jedes Team aus seiner lokalen Perspektive nachvollziehbar gehandelt hat. Die fehlende Begrenzung der gemeinsamen Ressource wird zum systemweiten Risiko.

Organisationsbeispiel

Ein ungeschützter Frontend-Monolith kann dieselbe Struktur zeigen. Viele Feature-Teams erweitern dieselbe Codebase, aber Verantwortlichkeiten, Review-Regeln und technische Grenzen bleiben unklar. Jedes Team integriert seine Logik dort, wo es kurzfristig am schnellsten geht. Mit der Zeit steigen Build-Zeiten, Kopplung und Regressionen. Die gemeinsame Codebase verliert Wartbarkeit, weil lokale Lieferziele stärker wirken als die Verantwortung für die gemeinsame technische Basis.

Diagnosefragen

1.Haben wir in unserer Cloud-Architektur kritische "Shared Services" (wie Kafka, Redis, API Gateways), bei denen wichtige Konsum-Anarchie herrscht und nie dokumentiert ist, wie viel Bandbreite "Fair Use" ist?

2.Wo dulden wir ein Management-Narrativ nach dem Motto "Geht alle nur schnell zum Ziel", und vernachlässigen völlig, den Teams klar zu kommunizieren, wer eigentlich für die Beseitigung der Spuren im Shared-System aufkommen muss?

3.Welche essenzielle Plattform-Technologie ist gerade kurz vor dem kompletten Ausfall, weil 50 Teams darauf "ihr Ding machen", ohne auch nur einen Cent an Contribution an das verantwortliche Team abzugeben?

Diagramm

Wie du das Muster im Alltag erkennst

Das Muster wird sichtbar, wenn eine Ressource "allen" gehört, aber niemand explizit für Verbrauch, Pflege und Weiterentwicklung verantwortlich ist. Appelle an Vernunft reichen selten aus, weil Teams unter lokalen Zielen, Deadlines und Anreizen handeln. Wirksamer sind klare Nutzungsregeln, transparente Kosten, technische Leitplanken und eine sichtbare Ownership für die gemeinsame Ressource.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Im Vergleich zu Limits to Growth entsteht die Grenze hier nicht nur durch das eigene Wachstum, sondern durch die Summe vieler lokaler Nutzungsentscheidungen. Das zentrale Problem ist die fehlende Kopplung zwischen Nutzung, Kosten und Verantwortung in einem gemeinsam genutzten System.

Wie du vom Muster zur Reaktion kommst

Verknüpfe Nutzung, Sichtbarkeit und Verantwortung. Für Shared-Ressourcen helfen klare Tenant Boundaries, Rate Limits, Quotas, API-Keys, Retention-Regeln und FinOps-Transparenz. Wenn Team A einen großen Anteil der Kafka-, Storage- oder Build-Kapazität nutzt, sollte dieser Verbrauch sichtbar und in der Planung berücksichtigt werden. So wird die gemeinsame Ressource nicht nur technisch, sondern auch organisatorisch geschützt.

Erste nächste Schritte

Mache Gemeingüter sichtbar. Wer Shared Services bereitstellt, sollte Nutzungsdaten, Grenzen, Verantwortlichkeiten und Eskalationswege von Beginn an mitdenken. Architektur braucht hier bewusste Reibung: nicht als Bürokratie, sondern als Feedback über reale Systemkosten.

Woran du das Muster sicher erkennst

Gibt es für zentrale Plattform- oder Infrastrukturressourcen klare Regeln für Nutzung, Quotas, Kostenverteilung und Ownership?

Quellen

Garrett Hardin — The Tragedy of the Commons (Science, 1968)

Elinor Ostrom — Governing the Commons (Cambridge UP, 1990)

Wikipedia: Tragedy of the Commons