Kontext
Im selben Quartal trafen zwei Extraktions-Vorschläge ein:
listingsextrahieren, aus Skalierungsgründen. Argument: Traffic auf listings wuchs, der Monolith würde "an eine Decke stoßen".notificationsextrahieren, wegen Team-Grenzen. Argument: die teamübergreifende Reibung am Notifications-Modul bremste alle aus.
Beide kamen von Senior-Engineers, die ich respektierte. Keiner kam mit den Daten, die ich brauchte.
Was ich verlangt habe
Für jeden Vorschlag, bevor ich ja oder nein sagen würde, brauchte ich:
- Den tatsächlichen Call-Graph. Welche anderen Module rufen dieses hier? Wie eng ist die Kopplung? Wie viele geteilte Typen?
- Die tatsächlichen Deploy-Konflikte. Sind wir wirklich im Shipping blockiert, oder ist es ein Gefühl?
- Den tatsächlichen Skalierungsdruck. Wie sieht der aktuelle p99 aus? Wo hat der Monolith CPU- und Memory-Headroom? Wann trifft die Wachstumskurve bei aktueller Rate die Decke?
- Die Team-Reibung, konkret benannt. Welche PRs haben Reibung ausgelöst? Wie sah das Gespräch aus?
Was wir fanden
Für die listings-Extraktion:
- RPS lag bei 18 % der Monolith-Kapazität. Bei aktueller Wachstumsrate würden wir die Decke in etwa sechs Jahren erreichen.
- Listings berührte sieben andere Module auf Type-Ebene. Eine Extraktion hätte ein geteiltes Schema-Paket gebraucht, sprich, wir hätten die Monolith-Grenze als Dependency-Edge neu erfunden.
Für die notifications-Extraktion:
- Die Deploy-Konflikt-Geschichte hielt nicht. Wir shippen eh viermal am Tag. Der "Konflikt" waren drei Slack-Nachrichten in den letzten sechs Monaten.
- Die Team-Reibung war real, aber die Ursache war eine unklare Eigentums-Grenze innerhalb des Moduls, fixbar mit einer dokumentierten RACI und einem CODEOWNERS-Update, nicht durch das Extrahieren eines Service.
Die Entscheidung
Monolithisch bleiben. Beide Module. Die Team-Reibung mit strikteren
Modul-Grenzen innerhalb des Monolithen lösen, eslint-plugin- boundaries, ein CODEOWNERS-Rewrite und eine dokumentierte interne API
für das Notifications-Modul.
Was eingetreten ist
Achtzehn Monate später kamen beide Vorschläge zurück, fast wortgleich. Dieselben Argumente. Derselbe Mangel an Daten.
Ich hatte die ursprüngliche Analyse griffbereit, ging sie mit den Vorschlagenden noch einmal durch, und die Antwort hielt. Die Notifications-Grenz-Arbeit hatte die echte Reibung gelöst; die Listings-Decke war nicht näher gerückt.
Was ich anders machen würde
Ich würde die Ablehnungs-Kriterien beim ersten Mal als durables Doc schreiben, nicht als Slack-Thread und Meeting-Zusammenfassung. Dieselbe Entscheidung ein Jahr später noch einmal aufzurollen kostete mich einen halben Tag Archäologie, Loom-Aufzeichnungen rauskramen, die Daten neu durchgehen, meine eigene Argumentation rekonstruieren.
Das Ablehnungs-Doc hätte die zweite Runde zu einem Fünf-Minuten-Link gemacht. Und, wichtiger, es hätte die Kriterien lesbar gemacht: zukünftige Vorschläge könnten dieselben Fragen vorwegnehmen, was du einer Senior-Person eigentlich abverlangen willst.