Der Betreiber will nicht, dass zweihundert Rechnungen als Schub bei einem
Empfaengerserver ankommen und die Absenderadresse dort als Spam eingestuft wird.
Heute sind es elf Kunden und zwei Rechnungen — die Regel wird fuer den Zustand
gebaut, in dem sie fehlen wuerde.
Drei Spuren, rund um die Uhr, kein Zeitfenster: Direkt (ungedrosselt), Wichtig
(30 je 5 Minuten), Zeit lassen (20 je 10 Minuten). Die Trennung laeuft nicht
zwischen Massenversand und Einzelmail, wie ich zuerst annahm, sondern zwischen
dringend und nicht dringend — eine Ausfallmeldung geht an alle UND eilt, und
bekommt deshalb ein hoeheres Kontingent statt gar keines.
Die sieben Direkt-Mails entstehen einzeln, weil ein Mensch gerade geklickt hat
und wartet. Sie koennen keinen Schub bilden; Drosseln nuetzt dort nichts und
kostet einen Supportfall je verzoegertem Kennwort. Sie lassen sich deshalb auch
nicht nach unten verschieben.
Gebaut wird es als Zwischenschicht an der Mail selbst: alle vierzehn Klassen
sind bereits ShouldQueue, und kein einziger Aufrufer aendert sich. Verworfen:
eine eigene Ausgangstabelle (zwanzig Absendestellen umbauen, zwei
Warteschlangen nebeneinander) und drei Arbeiter mit festem Takt (die Zahlen
staenden im Container statt in der Konsole).
Die Falle steht im Entwurf, weil sie den Bau still kaputtmachen kann: der
Arbeiter laeuft mit --tries=3, und eine gedrosselte Rueckstellung zaehlt als
Versuch. Ohne Vorkehrung waere jede Rechnung nach dem dritten Drosseln
gescheitert statt verschickt. Das ist der erste Test, vor der ersten Zeile
Drossel.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9e890243f6