Was vorher fertig sein muss
Das zu lösende Problem ist als ein bis zwei Sätze formuliert, mit erkennbarem Kontext und Reichweite über mindestens zwei Teams oder Komponenten.
Was vor Start vorliegen muss
RFC-Template im Repo (Kontext, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions, Migration); Repository oder Wiki für RFCs mit Nummerierung; Review-Tool mit Kommentaren (GitHub PR, GitLab MR, Notion Comments); Entscheidungs-Log.
Ein Autor (Senior-Engineer, Architekt, PM oder TL); 3-20 Reviewer aus betroffenen Teams; eine benannte Entscheidungsinstanz (Tech Lead, Architecture Review Board, oder klar gewählter Decider); ein Sponsor für umstrittene RFCs.
Problem-Beschreibung; bekannte Alternativen aus Vor-Diskussionen; betroffene Teams und Komponenten; Architektur-Constraints; gewünschter Entscheidungstermin; Status-Werte (Draft, In Review, Accepted, Rejected, Withdrawn).
1-3 Wochen vom Draft bis zur Entscheidung
RFC-Nummer und Datei im Repo angelegt. Reviewer und Decider benannt. Review-Fenster mit klarem Enddatum kommuniziert. Template-Sektionen befüllt mindestens als Skeleton.
Die eine Frage, die diese Methode beantwortet
Welche Änderung schlägt das Team vor, mit welcher Begründung, welchen Alternativen und welchen Tradeoffs, und wer entscheidet bis wann?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Kontext und Motivation | 60-90 min | Status Quo beschreiben: was existiert, was leidet, was passiert wenn nichts geschieht. Motivation: warum jetzt? Wer profitiert, wer trägt Kosten? Reichweite der Änderung (Teams, Services, Daten). | Wer mit Lösung startet, schreibt PR-Beschreibung, nicht RFC. Kontext ist mindestens 30% der Länge. Reviewer brauchen ihn, um Tradeoffs einzuordnen. |
2Sektion 2: Solution | 2-4 h | Vorgeschlagene Lösung detailliert: Architektur-Skizze, Schnittstellen, Datenmodell, Migration. So konkret, dass eine andere Person sie umsetzen könnte. Aber nicht Code-Level, sondern Design. | Zu vage: Reviewer können nicht bewerten. Zu detailliert: Diskussion verliert sich in Implementierung. Faustregel: Senior Engineer könnte daraus Tickets ableiten. |
3Sektion 3: Alternatives | 1-2 h | Mindestens 2-3 verworfene Alternativen mit Pro/Contra. Pro Alternative Begründung, warum nicht gewählt. Beinhaltet auch „nichts tun“ als Alternative. | Wer keine Alternativen nennt, hat nicht ergebnisoffen geprüft. Reviewer fragen sonst zu Recht: was wurde geprüft? Alternativen sind Beweis der Sorgfalt. |
4Sektion 4: Drawbacks und Unresolved Questions | 45-60 min | Ehrliche Nachteile der Lösung: was wird schwieriger, was kostet mehr, welches Risiko entsteht? Offene Fragen explizit als Liste, mit Vorschlag wie zu klären (Spike, Proof of Concept, externer Input). | Drawbacks-Sektion ist Lackmustest. Wenn dort nichts steht, ist Autor entweder zu enthusiastisch oder nicht gründlich. Mindestens 3 substantielle Drawbacks erwarten. |
5Sektion 5: Review-Runde | 1-2 Wochen Async-Review | RFC veröffentlichen, Review-Fenster (z. B. 10 Werktage). Reviewer kommentieren strukturiert. Autor antwortet auf jeden Kommentar, arbeitet ein oder lehnt ab mit Begründung. Status auf In Review. | Wer Kommentare ignoriert oder kosmetisch abhakt, verfehlt den Methoden-Zweck. Substantielle Kritik führt zu Überarbeitung. Glättung ist nicht Konsens. |
6Sektion 6: Entscheidung | 1-2 h | Benannte Entscheidungsinstanz setzt Status: Accepted, Rejected, Withdrawn. Bei Accepted: Folge-ADR oder Tickets. Bei Rejected: Begründung. Bei Withdrawn: Autor zieht zurück mit Erklärung. | Entscheidung ohne klare Instanz versumpft. Wenn kein Decider benannt war, ist das oft das eigentliche Problem. Diskussion ist kein Konsens, Entscheidung ist Akt. |
7Sektion 7: Übersetzung in Umsetzung | Stunden bis Tage | Bei Accepted: ADR mit Verweis auf RFC schreiben (kurze Entscheidungsbegründung). Tickets oder Issues ableiten mit Verweis auf RFC. Migration-Plan an betroffene Teams kommuniziert. | RFC ohne Umsetzung ist Diskussions-Theater. Pro angenommenes RFC mindestens ADR plus Issues. Owner für Umsetzung benannt. |
Was am Ende rauskommt
RFC-Dokument im Repo mit Nummer, Status, Autor, Datum, Review-Kommentaren, Antworten und finalem Status. Plus Folge-ADR und Issues mit RFC-Referenz. Decision-Log im RFC-Verzeichnis listet alle RFCs mit Status.
RFC-Nummer fortlaufend. Status-Übergänge protokolliert. Status Accepted führt zu ADR. Withdrawn-RFCs nicht löschen, sondern mit Status archivieren. Pro Major-Change-Request neuer RFC, nicht alter aufbohren.
Kompakte Arbeitsvorlage für Request for Comments mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Request for Comments Arbeitsvorlage
## Ziel
Strukturiertes Vorschlagsdokument, das eine nicht-triviale Änderung beschreibt und gezielt Feedback einsammelt.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- RFC-Dokument:
- Reviewer-Kommentare:
- Entscheidung mit Begründung:
- Folge-ADR oder Tickets:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## RFC #074 — Eigene Connection Pools für Batch-Workloads (Author @ben, Status: Accepted, 18.05.2026)
### Kontext
Unsere Order- und Payment-Services teilen sich heute Connection Pools (max 20 pro Service). Batch-Jobs greifen seit 2024 auf denselben Pool zu. Zwei Vorfälle (14.05.2026, 22.02.2026) zeigten, dass Batch-Workloads den Online-Traffic durch Pool-Auslastung blockieren können. Family-Tree-Analyse vom 18.05. zeigt Muster „Batch-Job ohne Quota teilt Online-Pool“ (3 Vorfälle in 15 Monaten).
### Motivation
Wiederholte Incidents kosten geschätzt 40k EUR pro Vorfall. Pattern ist nicht durch Punkt-Fix lösbar.
### Solution
Pro Service ein separater Batch-Pool mit eigener Quota (typisch 5 Connections). Batch-Workloads müssen explizit Batch-Pool nutzen (Annotation `@BatchPool` im Code). Code-Review-Checkliste erzwingt Annotation für Workloads über 30 s Laufzeit.
### Alternatives
1. Pool-Größe global erhöhen. Verworfen: löst Pattern nicht, nur verschiebt Schwelle.
2. Batch-Workloads auf separates DB-Replica. Verworfen: doppelte Infrastruktur, hohe Kosten, Konsistenz-Trade-off.
3. Nichts tun. Verworfen: Family-Tree zeigt Wiederholungs-Wahrscheinlichkeit hoch.
### Drawbacks
- Bestehende Batch-Jobs müssen migriert werden (geschätzt 14 Jobs, 4 Personen-Wochen).
- Pool-Tuning pro Service nötig, mehr Konfigurations-Aufwand.
- Code-Review-Disziplin wird zur Voraussetzung.
### Unresolved Questions
- Wie verhalten sich Batch-Pools bei Schema-Migrations? @lisa Spike bis 25.05.
- Sollten Health-Check-Workloads eigene Pools haben? Out-of-Scope für diese RFC.
### Migration
Phase 1: Order- und Payment-Service (bis 30.06.). Phase 2: Restliche Services (bis 30.09.). CODEOWNERS-Checkliste ab 28.05. aktiv.
### Review-Kommentare (Auszug)
- @anna: „Wie wird Pool-Größe pro Service dimensioniert?“ -> Autor: Faustregel 5 Connections plus 1 pro 100 erwarteter Batch-Operationen pro Stunde, Tuning-Doku in /docs/db/.
- @marcus: „Was bei Cron-Conflict?“ -> Autor: Out-of-Scope, eigener RFC geplant.
### Entscheidung
Decider: @julia (CTO). Status: Accepted am 17.05.2026.
### Folge
- ADR-2026-014 mit Verweis.
- Issues #1241-#1254 (14 Migrations-Tickets) erstellt.
- Owner Migration: @ben (Order, Payment), @sabine (Restliche Services).Symptome erkennen, gegensteuern
Dokument startet mit Lösung, Reviewer verstehen Motivation nicht.
Mindestens 30% des Texts für Kontext und Motivation. Wer Kontext nicht aufschreiben kann, hat Problem nicht durchdrungen.
Nur die gewählte Lösung steht im Dokument, Reviewer haben keine Vergleichsbasis.
Pflichtsektion Alternatives mit mindestens 2-3 Optionen plus Begründung Verwerfung. „Nichts tun“ ist immer eine Alternative.
Vorschlag wird als reiner Gewinn dargestellt, Reviewer misstrauisch.
Pflichtsektion Drawbacks mit mindestens 3 substantiellen Nachteilen. Wer keine findet, ist nicht gründlich genug.
Diskussion läuft 6 Wochen, niemand schließt RFC, Umsetzung ungeklärt.
Decider vor Start benennen. Review-Fenster mit hartem Enddatum. Wenn Decider abwesend ist, vertreten oder RFC pausieren.
Reviewer-Feedback wird abgehakt, substantielle Kritik im Wortlaut beantwortet aber nicht im Dokument.
Pro Kommentar entweder Einarbeitung, schriftliche Ablehnung mit Begründung oder Park-Status. Glättung verfehlt Methoden-Zweck.
RFC ist Accepted, niemand hat Tickets oder ADR daraus abgeleitet, Lösung schläft.
Accepted-RFC erzeugt pflichtig ADR und Tickets. Owner namentlich. Quartals-Audit aller Accepted-RFCs auf Umsetzungs-Status.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.