Die entscheidende Frage
Eine Queue ist ein Verarbeitungsvertrag. Welche Nachricht darf verloren gehen? Wann gilt sie als verarbeitet? Darf eine wiederholte Zustellung denselben Geschäftsvorgang erneut auslösen? Ohne diese Antworten ist die Wahl eines Ersatzsystems verfrüht.
Den Bestand gezielt prüfen
- Queues, Producer, Consumer und Nachrichtentypen erfassen.
- Transaktionsbindung zwischen Datenänderung und Nachricht bestimmen.
- Retries, Ablaufzeiten, Prioritäten und Fehlerwarteschlangen dokumentieren.
Das Zielbild ableiten
Ein dedizierter Message Broker, ein transaktionales Outbox-Muster oder eine Datenbank-Queue können je nach Anforderung passen. PostgreSQL LISTEN/NOTIFY ist ein Benachrichtigungsmechanismus und kein vollständiger Ersatz für eine dauerhafte AQ-Nachrichtenverarbeitung. Dauerhafte Datenhaltung und Zustelllogik müssen im Zielkonzept erkennbar sein.
Ein konkreter Prüfschritt
Als Pilot eignet sich ein abgegrenzter Nachrichtentyp. Dokumentieren Sie den Weg vom fachlichen Ereignis bis zum bestätigten Ergebnis. Jede Unterbrechungsstelle erhält einen definierten Wiederanlauf.
Vor der Freigabe nachweisen
- Consumer-Abbruch zwischen Verarbeitung und Bestätigung simulieren.
- Doppelte Nachrichten anhand fachlicher Schlüssel behandeln.
- Ausfälle von Datenbank und Broker getrennt testen.
- Rückstau, Wiederanlauf und Fehlernachrichten überwachen.
Originalquellen & Vertiefung
Die Empfehlungen sind eine fachliche Einordnung. Konkrete Optionen hängen von Quell- und Zielversion, Rechten und Betriebsmodell ab.