Skip to main content
Architecture9 min read

Die Architekturentscheidung, die niemand aufschreibt

Wir verbringen Wochen mit der Wahl zwischen Kafka und RabbitMQ, dokumentieren aber nie das Warum. ADRs dauern 15 Minuten und sparen monatelange ‚Warum haben wir das gemacht?‘-Gespräche.

Part ofProduct Systems->
By Jason TeixeiraDecember 20, 2025
ArchitectureDocumentationADRDecision MakingBest Practices
Share:
On this page

Vor sechs Monaten habe ich mich bei Nexural für Supabase statt Firebase entschieden. Ich hatte gute Gründe – PostgreSQL, Row-Level Security, selbst hostbar. Aber ich hätte diese Gründe fast vergessen. Das Einzige, was mich davor bewahrt hat, dieselbe Entscheidung erneut zu bewerten (und eine Woche zu verschwenden), war eine Markdown-Datei, die ich in 15 Minuten geschrieben habe.

Das Problem

Jedes Engineering-Team kennt diese Unterhaltung:

"Warum verwenden wir RabbitMQ statt Kafka?" "Ich glaube, Dave hat das entschieden. Dave ist vor 8 Monaten gegangen." "..." "Sollten wir zu Kafka wechseln?"

Und schon verbringst du einen Sprint damit, eine Entscheidung neu zu bewerten, die bereits bewertet wurde. Das institutionelle Wissen ist zur Tür hinausgegangen.

Architecture Decision Records (ADRs)

Ein ADR ist ein kurzes Dokument, das eine bedeutende Entscheidung festhält. Meine sind denkbar einfach:

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Architecture

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed