Claude für System Design Reviews nutzen

1. Was ein System Design Review mit Claude wirklich leistet

Ein klassisches System Design Review findet in einem Meeting statt: ein Architekt präsentiert ein Diagramm, das Team stellt Fragen, jemand schreibt Notizen mit. Das Problem dabei ist bekannt: Fragen entstehen spontan, hängen von der Tagesform der Anwesenden ab und werden selten vollständig protokolliert. Ein System Design Review mit Claude ergänzt dieses Format, indem es eine zweite, konsistente Prüfinstanz einführt, die dieselbe Architektur immer nach demselben Raster durchgeht: Skalierbarkeit, Konsistenzmodell, Fehlerdomänen, Sicherheitsgrenzen und Betriebskosten.

Wichtig ist die Erwartungshaltung. Claude kennt weder die interne Politik eines Unternehmens noch die tatsächliche Lastverteilung im Produktivbetrieb. Ein Claude System Design Review ersetzt daher nicht den erfahrenen Architekten, der Kontextwissen über das Team und die Historie des Systems mitbringt. Es ersetzt aber zuverlässig das stille Überlesen von Detailproblemen, die in einem einstündigen Meeting schlicht keine Zeit finden. Claude kann in derselben Zeit, in der ein Mensch das Diagramm einmal liest, das Dokument gegen Dutzende bekannte Architekturmuster und Anti-Pattern abgleichen.

In der Praxis funktioniert das System Design Review am besten als vorgelagerter Schritt vor dem menschlichen Meeting. Claude identifiziert offene Fragen und schwache Stellen im Entwurf, das Team diskutiert dann gezielt über diese Punkte, statt bei null anzufangen. Diese Reihenfolge, KI-Review vor Team-Review, hat sich in mehreren Projekten als deutlich effizienter erwiesen als der umgekehrte Weg.

2. Architekturdokumente als Input richtig vorbereiten

Die Qualität eines System Design Reviews mit Claude hängt direkt von der Qualität des Eingabematerials ab. Ein reines Diagramm ohne Textbeschreibung liefert zu wenig Kontext, denn Claude kann Bilder zwar interpretieren, aber Beschriftungen, Pfeile und implizite Annahmen werden in Textform präziser erfasst. Bewährt hat sich ein Format, das Komponenten, Datenflüsse, erwartete Last und explizite Nicht-Ziele in Fließtext beschreibt, ergänzt um ein einfaches Diagramm als visuelle Stütze.

Ein zweiter wichtiger Baustein sind die nicht-funktionalen Anforderungen. Ohne Angaben zu erwarteter Latenz, Durchsatz und Verfügbarkeitsziel kann kein System Design Review sinnvoll bewerten, ob eine Architekturentscheidung angemessen ist. Ein System, das 50 Anfragen pro Sekunde bedient, braucht andere Muster als eines mit 50.000. Claude fragt bei fehlenden Angaben in der Regel gezielt nach, aber wer diese Zahlen von Anfang an mitliefert, bekommt präzisere und schnellere Antworten.

# Prepare a structured design doc for Claude Code before the review session
mkdir -p docs/design-reviews
cat > docs/design-reviews/order-service-v2.md << 'DOC'
# Order Service v2 - Design Doc

## Goal
Split monolithic order processing into a dedicated service.

## Non-functional requirements
- Expected load: 300 req/s peak, 40 req/s average
- Target p99 latency: 200ms
- Availability target: 99.9%
- Consistency: strong for payment state, eventual for order history

## Components
- API gateway -> Order Service (REST) -> Payment Service (gRPC)
- Order Service writes to PostgreSQL (primary), publishes events to Kafka
- Read model in Elasticsearch, updated via Kafka consumer

## Explicit non-goals
- No multi-region active-active in this iteration
- No support for offline order creation
DOC

# Ask Claude Code to review the doc against the actual codebase
claude "Review docs/design-reviews/order-service-v2.md against the current
codebase in src/OrderService. Focus on scalability bottlenecks, consistency
guarantees between the Postgres write and the Kafka publish, and failure
domains. List concrete risks with severity, not general advice."

Bei einem Claude System Design Review lohnt sich außerdem, bestehenden Code als zusätzlichen Kontext mitzugeben. Claude Code kann direkt im Repository arbeiten und den geplanten Entwurf gegen den tatsächlichen Zustand der Codebasis abgleichen, statt nur die Theorie im Dokument zu bewerten. Das deckt Diskrepanzen zwischen geplanter und gelebter Architektur auf, die in einem reinen Diagramm-Review unsichtbar blieben.

3. Skalierbarkeit und Bottlenecks systematisch analysieren

Skalierbarkeit ist der Bereich, in dem ein System Design Review mit Claude besonders zuverlässig funktioniert, weil sich viele Skalierungsprobleme aus bekannten Mustern ableiten lassen. Claude prüft typischerweise: Wo liegt der Single Point of Failure? Welche Komponente wird bei steigender Last zuerst zum Flaschenhals? Gibt es einen zentralen Datenbank-Schreibpfad, der nicht horizontal skaliert? Diese Fragen lassen sich aus einer präzisen Architekturbeschreibung mit hoher Trefferquote beantworten.

Ein konkretes Beispiel aus der Praxis: In einem System Design Review für einen Checkout-Flow identifizierte Claude, dass der geplante Entwurf jede Bestellbestätigung synchron gegen drei externe Zahlungsanbieter validierte, bevor die Antwort an den Kunden ging. Bei 300 Anfragen pro Sekunde und einer durchschnittlichen externen Latenz von 400 Millisekunden pro Anbieter hätte das die Zielzeit von 200 Millisekunden p99 unmöglich gemacht. Die Lösung, asynchrone Validierung mit optimistischer Bestätigung, wurde erst durch diese Rechnung im Review sichtbar, nicht durch das Diagramm allein.

Wichtig ist, dass Claude bei der Skalierbarkeitsanalyse konkrete Zahlen einfordert, statt vage Aussagen zu akzeptieren. Ein guter Prompt für ein Claude System Design Review verlangt explizit: „Rechne mit den angegebenen Lastzahlen durch, ob Komponente X den Durchsatz schafft, und zeige die Rechnung.“ Ohne diese Aufforderung bleiben Antworten oft auf der Ebene allgemeiner Best Practices stehen, was für einen wirklich belastbaren System Design Review zu wenig ist.

4. Konsistenz und Verfügbarkeit: CAP-Tradeoffs bewerten

Jedes verteilte System trifft implizit eine Entscheidung zwischen Konsistenz und Verfügbarkeit, sobald ein Netzwerkpartition-Szenario eintritt. Ein sauberes System Design Review mit Claude macht diese Entscheidung explizit, statt sie unausgesprochen im Code verschwinden zu lassen. Claude kann pro Komponente einordnen, ob strenge Konsistenz, sequenzielle Konsistenz oder eventuelle Konsistenz vorliegt, und ob diese Wahl zur fachlichen Anforderung passt.

Ein häufiges Muster, das im Review auffällt: Ein Team wählt eventuelle Konsistenz für ein Zahlungsdatenmodell, weil das allgemein als „skalierbares Pattern“ gilt, ohne zu bedenken, dass doppelte Gutschriften oder verlorene Stornierungen fachlich inakzeptabel sind. Ein gründliches System Design Review stellt hier gezielt die Gegenfrage: Welche fachliche Konsequenz hat ein Konsistenzverlust in diesem konkreten Datenmodell, und ist das Team bereit, diese Konsequenz zu tragen?

{
  "review_finding": "consistency-tradeoff",
  "component": "PaymentLedgerService",
  "current_design": "eventual consistency via Kafka, read model updated async",
  "risk": "double-credit possible during consumer lag or replay",
  "business_impact": "financial correctness violated, manual reconciliation required",
  "recommendation": "strong consistency for ledger writes (synchronous DB transaction), eventual consistency acceptable for read-only reporting views",
  "severity": "high",
  "requires_human_decision": true
}

Das Ergebnis eines solchen System Design Reviews ist selten eine fertige Entscheidung, sondern eine klar formulierte Frage mit Konsequenzen, die das Team dann bewusst beantwortet. Genau das ist der Mehrwert: Claude trifft die Tradeoff-Entscheidung nicht selbst, aber es verhindert, dass sie implizit und unbemerkt getroffen wird.

5. Sicherheitsarchitektur im Review: Threat-Modeling-Unterstützung

Ein vollständiges System Design Review bezieht Sicherheitsaspekte von Anfang an mit ein, statt sie als separaten Schritt nach der Implementierung nachzuschieben. Claude eignet sich gut für ein leichtgewichtiges Threat Modeling nach dem STRIDE-Schema (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege), angewendet auf jede Komponente und jede Vertrauensgrenze im Entwurf.

Bei einem Claude System Design Review für eine neue Authentifizierungskomponente identifizierte diese Methode zum Beispiel, dass ein internes Service-zu-Service-Gespräch ohne mTLS geplant war, weil das Team implizit davon ausging, dass internes Netzwerk gleichbedeutend mit vertrauenswürdig ist. Diese Annahme, in Sicherheitskreisen als Zero-Trust-Verletzung bekannt, wäre in einem reinen Funktions-Review kaum aufgefallen, weil der Code an sich fehlerfrei funktionierte.

Wichtig: Claude ersetzt kein formales Penetration Testing und keine spezialisierte Sicherheitsprüfung durch Experten. Ein System Design Review mit KI-Unterstützung ist ein zusätzlicher, früher Filter, der offensichtliche strukturelle Schwächen aufdeckt, bevor teurere und spätere Prüfungen überhaupt ansetzen.

6. Kosten- und Infrastruktur-Impact abschätzen lassen

Architekturentscheidungen haben direkte Kostenkonsequenzen, die in einem reinen technischen System Design Review oft untergehen. Claude kann, ausgehend von den angegebenen Lastzahlen, grobe Schätzungen zu Infrastrukturkosten liefern: Wie viele Instanzen einer bestimmten Größe werden bei der erwarteten Last benötigt, welche Datenmenge fällt bei welcher Retention an, welche Kosten entstehen durch zusätzliche Netzwerktransfers zwischen Regionen.

Diese Schätzungen sind bewusst grob und ersetzen keine detaillierte Kostenkalkulation durch das Infrastruktur-Team. Der Wert liegt darin, dass ein System Design Review mit Claude teure Entwurfsentscheidungen frühzeitig sichtbar macht, etwa eine geplante Architektur mit synchroner Cross-Region-Replikation, deren Netzwerkkosten bei realistischer Last ein Vielfaches der eigentlichen Compute-Kosten ausmachen würden. Ein solcher Hinweis im Review verändert oft die gesamte Diskussion, bevor ein einziger Server provisioniert wird.

7. Review-Ergebnisse als Architecture Decision Record festhalten

Ein System Design Review, dessen Ergebnisse nirgendwo landen, verpufft beim nächsten Teammitglied, das dieselbe Frage sechs Monate später erneut stellt. Architecture Decision Records, kurz ADR, sind das etablierte Format, um Entscheidungen mit Kontext, Alternativen und Begründung dauerhaft festzuhalten. Claude eignet sich hervorragend dafür, aus einer Review-Diskussion automatisch einen sauber strukturierten ADR-Entwurf zu erzeugen.

Der Prozess sieht in der Praxis so aus: Nach dem Claude System Design Review und der anschließenden Team-Diskussion fasst Claude die getroffene Entscheidung, die verworfenen Alternativen und die konkreten Gründe in einem ADR-Dokument zusammen. Das Team prüft und korrigiert diesen Entwurf, statt ihn komplett neu zu schreiben, was den Dokumentationsaufwand spürbar senkt und die Wahrscheinlichkeit erhöht, dass ADRs tatsächlich gepflegt werden.

# Generate an ADR draft from review notes with Claude Code
claude "Read docs/design-reviews/order-service-v2.md and
docs/design-reviews/review-notes-2026-07-28.md. Draft an Architecture
Decision Record in the MADR format under
docs/adr/0014-order-service-consistency-model.md. Include: Context,
Decision Drivers, Considered Options, Decision Outcome, Consequences.
Keep it factual, do not invent decisions that were not discussed."

8. Typische Fehler beim KI-gestützten Design Review

Der häufigste Fehler ist blindes Vertrauen in die Vollständigkeit des System Design Reviews. Claude bewertet nur, was im Eingabedokument steht. Fehlt eine Komponente in der Beschreibung, taucht sie auch nicht in der Analyse auf, selbst wenn sie im echten System existiert und kritisch ist. Wer ein unvollständiges Dokument einreicht, bekommt ein unvollständiges Review, unabhängig davon, wie gründlich die Analyse für den beschriebenen Teil ausfällt.

# Pseudo-checklist a reviewer runs before trusting an AI system design review
checklist = {
    "all_components_documented": False,   # missing components = blind spots
    "load_numbers_provided": False,       # vague load = vague analysis
    "non_goals_stated": False,            # scope creep risk otherwise
    "existing_code_referenced": False,    # design vs. reality drift
    "failure_domains_listed": False,      # partial reviews miss cascading failures
}

def is_review_input_reliable(checklist: dict) -> bool:
    """A design review is only as good as its input completeness."""
    return all(checklist.values())

Ein zweiter Fehler ist das Ignorieren von organisatorischem Kontext. Claude kennt keine internen Team-Kapazitäten, keine laufenden Migrationsprojekte und keine politischen Zwänge, die eine technisch optimale Lösung praktisch unmöglich machen. Ein System Design Review mit Claude liefert die technische Perspektive, die menschliche Einordnung in den organisatorischen Rahmen bleibt Aufgabe des Teams. Ein dritter Fehler: das Review als einmaligen Schritt statt als wiederkehrenden Prozess zu behandeln. Architekturen verändern sich, und ein Review, das ein Jahr alt ist, spiegelt selten den aktuellen Zustand.

9. System-Design-Review-Methoden im Vergleich

Die folgende Übersicht ordnet den Claude System Design Review gegenüber etablierten Alternativen ein. Keine der Methoden schließt die anderen aus, in der Praxis funktioniert die Kombination am besten.

Der praktische Ablauf, der sich bewährt hat: zuerst ein System Design Review mit Claude als schneller, günstiger erster Filter, danach das Team-Meeting mit den bereits identifizierten offenen Fragen, bei hochkritischen Systemen ergänzt um ein formales Review Board oder externe Expertise für die finale Freigabe.

10. Zusammenfassung

Ein System Design Review mit Claude funktioniert am besten als vorgelagerter, systematischer Filter vor dem menschlichen Architektur-Meeting. Claude prüft Skalierbarkeit anhand konkreter Lastzahlen, macht CAP-Tradeoffs explizit, wendet ein leichtgewichtiges Threat Modeling an und schätzt grobe Infrastrukturkosten. Die Qualität des Reviews hängt direkt von der Qualität des Eingabedokuments ab: vollständige Komponentenliste, konkrete Lastzahlen und explizite Nicht-Ziele sind Pflicht.

Claude ersetzt keinen erfahrenen Architekten und kein formales Architecture Review Board bei hochkritischen Systemen, aber es verhindert zuverlässig, dass offensichtliche strukturelle Schwächen unbemerkt in die Implementierung wandern. Die anschließende Dokumentation als Architecture Decision Record, ebenfalls mit Claude vorbereitet, sorgt dafür, dass die Entscheidung und ihre Begründung auch Monate später nachvollziehbar bleiben.

11. FAQ: Claude für System Design Reviews