Architecting for Scale: Selbstgenügsame Teilsysteme und autonome Teams – Einblicke aus „Architecting for Scale“ von David Leitner (SQUER)

Worum es in diesem Talk wirklich geht

Wir bei DevJobs.at haben „Architecting for Scale“ von David Leitner (SQUER) in Linz verfolgt – ein dichtes, praxisnahes Plädoyer dafür, Skalierung als sozio‑technische Aufgabe zu begreifen. Leitner, Chief Technology bei SQUER und selbsternannter „Coding Architect“, betont: Qualität entsteht nicht nur auf der Architektur‑Ebene, sondern ebenso in Design und Implementierung. Und: Skalierung gelingt, wenn Teams wirklich autonom handeln können – fachlich und technisch.

Leitner ordnet den Talk in die vier Tätigkeitsfelder von SQUER ein: Organisationen in die Lage versetzen, digitale Produkte zu bauen, nachhaltige Produktentwicklung (von Design‑Thinking bis Umsetzung), Software‑Transformation (z. B. Monolithen zerlegen, Technologien modernisieren) sowie Cloud‑ und Plattform‑Engineering. „Architecting for Scale“ berührt alle vier, weil Skalierung unausweichlich sowohl Organisations‑ als auch Architekturfragen zusammenführt.

Vom einfachen System zum komplexen Umfeld

Der typische Verlauf: Zwei Leute bauen etwas Wertvolles, es funktioniert, erzeugt Nutzen – und das Team wächst. Mehr Teams, mehr Features, mehr Abhängigkeiten. Erfolg zwingt zur Skalierung. Doch in der Realität machen viele Organisationen dieselbe Erfahrung: Der Output wächst nicht proportional zur Anzahl der Entwicklerinnen und Entwickler. Im Gegenteil, Ausfälle häufen sich.

Das läuft den Zielen zuwider, die „Flow of Value“ zu optimieren und – wie Leitner formuliert – „sicher und nachhaltig die Lead Time to Thank You zu reduzieren“. Die Frage ist also: Wie schneiden wir Systeme so, dass sie mit mehreren Teams verlässlich und mit hoher Geschwindigkeit weiterentwickelt werden können?

Modularisierung ist nicht gleich Verteilung

Leitner sortiert ein weit verbreitetes Missverständnis: Modularisierung und Verteilung sind zwei verschiedene Achsen. Wir können gut oder schlecht modularisieren – und wir können monolithisch oder verteilt deployen. Häufig landen wir historisch in der worst‑case‑Ecke: ein monolithisches Deployment mit schlechter Modularisierung – die berüchtigte „Big Ball of Mud“.

Daraus folgt nicht automatisch, dass verteilte Deployments die Modularisierung verbessern. Im Gegenteil: Wer Modularisierung durch Microservices ersetzen will, riskiert den „verteilten Monolithen“ – die Nachteile beider Welten zugleich: hohe Kopplung plus Netzwerkkomplexität.

Ein Satz, den Leitner zitiert, bringt es auf den Punkt:

Die Folgerung: Wer Modularisierung will, soll modularisieren. Verteilung ist dafür kein Ersatz – und meist nicht die primäre Begründung.

Warum wir dennoch verteilen: Autonomie schlägt Technik

Es gibt technische Gründe für verteilte Architekturen:

• individuelle Skalierungsanforderungen einzelner Teile,
• Technologie‑Segmentierung (z. B. ML‑Komponenten in Python, Backends in Go/Java),
• Co‑Location (Teile nahe am Kunden oder nahe an externen Abhängigkeiten betreiben).

In der Praxis sind diese Gründe selten ausschlaggebend. Der Haupttreiber ist organisatorisch: Ownership und Autonomie.

„You build it, you run it“ funktioniert schlecht, wenn alle Teams auf einem gemeinsamen Deployment sitzen. Ein Fehler in Modul B kann Modul A und C mitreißen – Team A wird niemals verlässlich „Own it“ versprechen, solange es den Gesamtkontext nicht kontrollieren kann. Verteilung ist dann ein Mittel, das Kontrollierbare in die Hände der Verantwortlichen zu legen.

Die „Architektur für Skalierung“ ist somit strukturgebend für die Organisation: Wir schneiden Systeme so, dass Teams fachliche Ende‑zu‑Ende‑Verantwortung tragen und ihren technischen Betrieb wirklich kontrollieren können. Leitners Zielbild: selbstgenügsame, autonome Teilsysteme – häufig als grobgranulare Microservices („self‑contained systems“) realisiert.

Das Leitprinzip: selbstgenügsame Teilsysteme

Leitner formuliert es klar:

Wie sieht das konkret aus? Leitner illustriert das an einem E‑Commerce‑Beispiel mit einem Payment‑Team und einem Account‑Team.

Outgoing‑Abhängigkeiten: Resilienz statt Dominoeffekt

Der Payment‑Service ist down. Das Payment‑Team sagt: „Nicht unsere Schuld, der Account‑Service liefert keine Userliste.“ Die naheliegende Antwort: „Es ist euer Service – ihr seid dafür verantwortlich, dass ein Nutzer zahlen kann.“

Was folgt, sind Architekturmuster für Resilienz:

• Caching der benötigten Userdaten, statt die Account‑API zur Laufzeit hart zu fronten.
• Event‑Streams (z. B. ein Kafka‑Topic mit User‑Änderungen) konsumieren und eine lokale, aktuelle Sicht (Schutzschicht) aufbauen.

So bleibt Payment funktionsfähig, selbst wenn Account temporär ausfällt. Das Bild dahinter: Ereignisgetriebene, reaktive Architekturen reduzieren Kopplung, verbessern Fehlertoleranz und unterstützen Team‑Autonomie. Leitner verweist auf einen separaten Vortrag zur „Rise of Reactive Microservices“, geht hier aber bewusst nicht tiefer ins Pattern‑Inventar – das Prinzip reicht: Baue lokalen Schutz gegen externe Ausfälle.

Incoming‑Abhängigkeiten: Gegenverkehr ist dein Problem

Ebenso wichtig sind eingehende Abhängigkeiten: Aufrufer können dich versehentlich fluten, falsch konfigurieren oder schlicht instabil sein. „Dann ist es wieder dein Problem“, sagt Leitner. Du kontrollierst externe Systeme nicht – also musst du dich aktiv schützen:

• Load Balancer sinnvoll einsetzen,
• Circuit Breaker, Timeouts, Retries,
• gezieltes Caching der Antworten.

Kurz: „Wir müssen mit externem Failure im Kopf designen.“ In verteilten Systemen wird alles, was schiefgehen kann, irgendwann schiefgehen.

Chaos einkalkulieren: Game Days am Nachmittag

Stabile Produktion ist kein Selbstzweck, wenn Stabilität nur oberflächlich ist. Leitners Plädoyer: Bewusst Chaos erzeugen, solange das ganze Team aufmerksam und verfügbar ist. Game Days am Nachmittag, nicht Alarme um drei Uhr morgens.

• „Wir schalten die Datenbank aus. Was passiert?“
• „Die Netzwerkverbindung zwischen A und B bricht – wie verhalten sich die Systeme?“
• „Ein Service ist falsch konfiguriert – wie bricht der Fehler durch?“

Ziel ist, Prozesse, Self‑Healing und Recovery zu verankern. „Chaos ist in komplexen, verteilten Systemen unvermeidbar – also plant es ein.“

Über Technik hinaus: fachliche Ende‑zu‑Ende‑Verantwortung

Man kann die perfekte technische Plattform hinstellen – ohne die richtige fachliche Schnitt bleibt das Team abhängig. Leitner bringt wieder das Payment‑Beispiel:

Ein Payment wird ausgelöst, aber die Payment‑Gateway‑Komponente wirft Fehler. Man könnte natürlich versuchen, das Gateway‑Team stabiler zu machen. Die bessere Frage ist jedoch: Warum ist das Gateway überhaupt ein separates Team/eine getrennte Domäne? Wenn Payment Ende‑zu‑Ende in einer Hand liegen soll, dann schneidet man vertikal.

Leitners Vorschlag: Wenn Payment zu groß für ein Team ist, dann fachlich sinnvoll segmentieren – z. B. ein Team für Kreditkarten‑Zahlungen und eines für SEPA‑Zahlungen. Beide tragen Ende‑zu‑Ende‑Verantwortung für „ihre“ Bezahlverfahren. So muss das SEPA‑Team nicht ständig „nach oben“ delegieren – und kann schneller liefern.

Komplizierte Subsysteme auslagern – mit klaren Erwartungen

Nicht alles kann in ein Stream‑aligned‑Team. Beispiel: Fraud‑Check als eigenes, kompliziertes Subsystem. Das schützt kognitiv und organisatorisch die wertstiftenden Teams – erhöht aber die Integrationsanforderungen. Was zwingend dazugehört:

• gegenseitiges Verständnis über Verfügbarkeit (die berühmten „Neuner“),
• Lightweight‑SLAs – keine Overhead‑Monster, aber klare Erwartungen,
• Architekturkonzepte, die zur Verfügbarkeit passen.

Leitner macht die Konsequenzen greifbar: Wenn das Fraud‑Subsystem „drei Neuner“ hat (≈ neun Stunden im Jahr down), muss Payment anders integrieren als bei „fünf Neunern“ (≈ sechs Minuten im Jahr down). Bei drei Neunern braucht es z. B. eine „Wir nehmen die Zahlung an und wenden sie später an“‑Strategie; bei fünf Neunern kann man dem Kunden oft einfach einen höflichen Retry‑Dialog anbieten.

Wichtige Kennzahl ist auch die „Mean Time to Failure“: Wie oft fällt etwas aus? Gegen manche Systeme (z. B. Legacy Core Backends) muss man explizit entkoppeln, damit ein Ausfall nicht den gesamten Geschäftsprozess blockiert.

Plattform‑Teams als Enabler – ebenfalls mit SLAs

Leitner knüpft an bekannte Muster (Team Topologies) an: Plattform‑Teams, die Stream‑aligned‑Teams unterstützen – etwa indem sie Kubernetes betreiben oder geteilte Cloud‑Ressourcen verantworten. Auch hier gilt: Erwartungen klären. Welche „Neuner“ liefert die Plattform? Welche Services sind „golden path“, welche „best effort“? Ohne diese Verständigung lässt sich Verfügbarkeit auf den geschäftskritischen Pfaden nicht sauber architektonisch abbilden.

Der Gesamtzusammenhang: Sozio‑technisches Design für Flow und Stabilität

Leitners Gesamtbotschaft: Skalierung ist keine rein technische Übung. Es geht um Architektur UND Organisation – um technische Exzellenz gekoppelt mit Teamzuschnitt, Ownership und Ende‑zu‑Ende‑Verantwortung.

Er fasst vier konkrete Prinzipien zusammen, die aus dem Talk hängen bleiben:

1. Mit externem Failure rechnen – es ist gegeben, nicht optional.
2. Chaos einkalkulieren – Game Days, Ausfälle provozieren, Recovery lernen.
3. Um Ende‑zu‑Ende‑Verantwortungen herum schneiden – vertikal statt horizontal.
4. Für Verfügbarkeit auf kritischen Pfaden designen – Abhängigkeiten mit „Neunern“ und MTTF verstehen und entsprechend integrieren.

Daneben erwähnt Leitner, dass er in einer ähnlichen Präsentation noch drei weitere Punkte vertieft – in diesem Talk bleibt der Fokus auf den vier oben genannten.

Praktische Schritte: Was Teams jetzt konkret tun können

Aus dem Gesagten lassen sich unmittelbare Maßnahmen ableiten. Ohne neue Tools zu erfinden, nur durch konsequentes Anwenden der genannten Prinzipien:

• Abhängigkeiten kartieren: Outgoing und Incoming. Wo sind wir anfällig? Was ist kritisch für unseren „Lead Time to Thank You“?
• Vertikal schneiden: Prüfen, ob fachliche Ende‑zu‑Ende‑Schnitte möglich sind (z. B. Kreditkarte vs. SEPA), statt horizontale Komponenten zu bilden (z. B. separates „Gateway‑Team“).
• Selbstschutz etablieren: Caching, Event‑Streams (z. B. Nutzer‑Änderungen), lokale Projektionen – damit Ausfälle anderer Teams nicht unseren Pfad blockieren.
• Defensive Patterns aktivieren: Circuit Breaker, sinnvolle Timeouts, saubere Retries, Lastmanagement über Load Balancer.
• „Neuner“ klären: Mit komplizierten Subsystemen und Plattform‑Teams pragmatische, leichte SLAs vereinbaren. Neun Stunden vs. sechs Minuten Downtime/Jahr führen zu anderen Integrationsstrategien.
• MTTF ernst nehmen: Frequenz von Ausfällen ist genauso wichtig wie ihre Länge. Hochfrequente Miniausfälle können komplexe Kaskaden auslösen – entsprechend entkoppeln.
• Chaos üben: Geplante Game Days am Nachmittag. Datenbank aus, Netzwerk getrennt, Konfigurationen verdreht – das ganze Team lernt gemeinsam.

Fazit: Architektur als Enabler von Autonomie

„Architecting for Scale“ von David Leitner (SQUER) liefert eine klare Richtschnur: Nicht Microservices per se sind die Lösung, sondern der Schnitt in selbstgenügsame Subsysteme, die autonome Teams befähigen. Verfügbarkeit, Robustheit und Geschwindigkeit entstehen dort, wo Teams Ende‑zu‑Ende‑Verantwortung tragen und sich technisch gegen die Unwägbarkeiten verteilter Systeme wappnen.

Leitner startete mit der Beobachtung, dass Wachstum ohne Struktur schnell zu komplexen Systemen führt, in denen mehr Peopleware nicht automatisch mehr Wert schafft – oft sogar das Gegenteil. Seine Antwort bleibt konsequent: Architektur so gestalten, dass Teams Eigentum übernehmen können („build it and run it“), externe Ausfälle verkraften, Chaos aktiv trainieren und in ihren kritischen Pfaden mit klaren Erwartungen planen. So wird Skalierung zum Verbündeten – und der Weg von der Idee bis zum „Thank You“ kurz gehalten.

• 

  

  Domain Driven Kitchen Madness

  Maurizio Rinder von SQUER überlegt in seinem devjobs.at TechTalk wie man ein hervorragendes italienisches Mahl organisiert und warum die selben Überlegungen auch gut für die Software Entwicklung sind.

  Jetzt ansehen

• 

  

  David Leitner, Co-Founder von SQUER

  David Leitner von SQUER gibt im Interview Einblicke in die Arbeitsweise der Developer im Unternehmen, auf was beim Recruiting geachtet wird und spricht über die verwendeten Technologien.

  Jetzt ansehen

• 

  

  Julia Toifl, Senior Full Stack Engineer bei SQUER

  Julia Toifl von SQUER spricht in ihrem Interview über ihren unerwarteten Einstieg in die IT als Physikerin, was die aktuelle Arbeit im Full Stack Engineering umfasst und gibt Tipps für Neueinsteiger.

  Jetzt ansehen