Transaktions-Messaging

Transaktionales Messaging ist eine Reihe von Architekturtechniken, die Konsistenz zwischen lokalen Zustandsänderungen (DB/Cache) und Nachrichten im Broker/Bus gewährleisten. Zweck: „Der Status ist festgelegt ↔ die Nachricht ist nicht verloren oder dupliziert“, wenn Fehler, Retrays, Skalierung und Multi-Tenant auftreten.

1) Semantik der Lieferung

At-most-once: schnell und günstig, Verluste möglich, keine Takes.
At-least-once: Verliert keine Nachrichten, Doppel sind möglich → Idempotenz ist erforderlich.
(Effective) Exactly-once: kein Verlust und keine sichtbaren Takes für Business-Effekte, erreicht durch eine Kombination von Techniken (Outbox/Inbox, Producer/Consumer-Transaktionen, Dedup).

2) Warum „zwei Buchstaben“ gefährlich sind

Die naive Logik „Zuerst schreiben wir es in die Datenbank, dann senden wir es an den Bus“ (oder umgekehrt) bricht, wenn es zwischen den Schritten fällt: Die Daten sind festgelegt, und das Ereignis ist verloren; entweder das Ereignis ist weg, aber es gibt keine Daten. Transaktionales Messaging schließt diese Lücke.

3) Grundmuster

3. 1 Outbox (Hersteller)

In einer lokalen Transaktion schreiben wir die Geschäftsänderung und die Zeile in die Tabelle' outbox'; ein einzelner Pablisher liest die Outbox und veröffentlicht sie im Broker mit Retrays und Backoff. Verluste sind ausgeschlossen; Doppel löschen idempotentia bei den Verbrauchern.

3. 2 Inbox/Idempotent Consumer (Verbraucher)

Vor der Ausführung des Effekts macht der Consumer 'INSERT' in 'inbox (consumer, event_id)' als Primärschlüssel. Schlüsselkonflikt = Ereignis bereits verarbeitet → übersprungen. So werde ein „effektives Exactly-once“ erreicht.

3. 3 Read-Process-Write mit Offset-Transaktion

Vorlage für Log-orientierte Busse: Der Consumer liest den Batch, in derselben Transaktion erfasst er die Geschäftsänderung und das „bestandene Offset“. Nach dem Commit hält der Broker die Nachrichten für verbraucht. Dies beseitigt das „Lesen → Fallen → Wiederholen“ ohne Doppelungen im Effekt.

3. 4 TCC/Sagas für Service-übergreifende Effekte

Wenn Sie einen konsistenten mehrstufigen Prozess benötigen, verwenden Sie TCC oder Sagas; Nachrichten - Transport von Befehlen/Ereignissen und Transaktionalität - auf der Ebene der Schritte und Kompensationen.

4) Idempotente Produzenten und Konsumenten

Producer: Stable' message _ id '/' idempotency _ key', wiederholtes Senden mit dem gleichen Schlüssel erzeugt keine neuen Effekte bei Abonnenten; Halten Sie die Sequenz (sequence) durch den Schlüssel.
Consumer: 'inbox' + geschäftliche Idempotenz (upsert/merge, Überprüfung der neuesten Version/Revision).

5) Ordnung und Kausalität

Partitionieren Sie nach Geschäftsschlüssel (z.B. 'aggregate _ id', 'tenant _ id'), damit die Ereignisse eines Objekts in Ordnung kommen.
Halten Sie innerhalb der Partei aufeinanderfolgende Zahlen/Zeitstempel; Beim Redrave aus dem DLQ „nach Schlüssel und konsequent“ beachten.
Wenn die globale Ordnung nicht kritisch ist, stellen Sie die lokale Ordnung durch den Schlüssel sicher und fixieren Sie die Invarianten der Domäne.

6) Offsets und Fixierung von Effekten

Variante A: „Offset in der DB“

Schreiben Sie das „zuletzt verarbeitete Offset (Partition, Offset)“ in dieselbe Transaktion, in der Sie die Domänendaten ändern. Wenn Sie neu starten, fahren Sie mit dem nächsten Offset fort und vermeiden Sie einen Re-Effekt.

Variante B: „Broker-Transaktion“

Einige Broker unterstützen die atomare Aufzeichnung von Nachrichten und Offsets innerhalb einer einzigen Producer/Consumer-Transaktion. Verwenden Sie, wenn verfügbar, aber immer mit idempotentia auf dem Verbraucher ergänzen.

7) Retrays, Backoff, DLQ

Wiederholen Sie nur Retraible-Fehler (Timeouts, 5xx), mit exponentiellem Backoff und Jitter.
Non-Retraible (Schema/Validierung) - sofort in DLQ mit Metadaten (Tenant, Key, Offset, Ursache).
Redrive von DLQ dosieren (Batch, Rate Limit), überprüfen Sie das Schema vor der Wiederholung, halten Sie die Reihenfolge nach Schlüssel ein.

8) Multi-Tenante und Regionen

Fügen Sie' tenant _ id', 'plan', 'region' in die Metadaten der Nachricht und die Partitionierungsschlüssel ein.
Per-tenant fairness: Limitieren Sie die Veröffentlichung/Bearbeitung, damit der „laute“ Kunde den anderen nicht das Budget wegnimmt.
Residency: Speichern Sie Nachrichten und Outbox in der gleichen Region wie die Domain-Daten; interregionale Replikationen - asynchrone Aggregate.

9) Beobachtbarkeit und Audit

Tracing: Korrelation 'event _ id '/' aggregate _ id '/' saga _ id', Spans' read → process → write/commit'.
Metriken: Veröffentlichungs-/Verarbeitungs-Lag (p95/p99), Erfolgsquote, DLQ-Rate, Redrive-Erfolg, „Duplikate unterdrückt“.
Logs: kurz zum Erfolg; im Detail auf Fehler (Ursache, Versuch, Schlüssel, Offset).
Audit: Wer redrayvill/rollte zurück, mit welchem Batch und mit welchem Ergebnis.

10) Sicherheit und Compliance

Minimieren Sie PII in payload; Maskieren, wenn in DLQ/Logs übertragen.
Signieren/Verschlüsseln von Nachrichten für externe Busse; Verwenden Sie mTLS zwischen den Diensten.
Verwalten Sie die Aufbewahrungsfrist und das „Recht auf Vergessenwerden“ per tenant/region.

11) Typische Integrationsregelungen

1. Quelldienst (write-side)

Lokale Transaktion: Domain-Eintrag + Outbox.
Pablisher: Batchi, 'SKIP LOCKED', Backoff, Limits per tenant.
Überwachung der Laga 'now − occurred_at'.

2. Service-to-consumer (read-side)

Batch lesen → Versuch 'INSERT inbox (consumer, event_id)' → Wenn wir erfolgreich sind, führen wir den Effekt aus.
In der gleichen Transaktion erfassen wir das „bestandene Offset“ (Variante A) oder verlassen uns auf die Transaktion des Brokers (Variante B).
Auf Fehler: Retray- oder DLQ-Richtlinie.

3. Projektion/materialisierte Ansicht

Nur idempotente Upgrades (upsert), kompakte Deduplizierungsschlüssel, periodischer Checksummenabgleich.

12) Konfigurationsvorlagen (Beispiel)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Checkliste vor dem Verkauf

• Eliminierte „Zwei-Buchstaben“: Outbox auf dem Hersteller oder Fixierung von Offset und Effekt in einer einzigen Transaktion im Consumer.
• Idempotent consumer: 'inbox '/dedup journal, business idempotence of operations.
• Partitionierung nach Geschäftsschlüssel, lokale Reihenfolge eingehalten.
• Retrays mit Backoff + Jitter, Fehlerklassifizierung, DLQ mit reichhaltigen Metadaten.
• Redrive dosiert, sicher; Es gibt Playbooks.
• Multi-Tenant-Grenzen und -Prioritäten; Tags' tenant _ id/plan/region'.
• Telemetrie: Lags, Erfolgsquote, „Duplikate unterdrückt“, Warnungen nach p95/p99.
• Die PII/Retention/Encryption-Richtlinien wurden eingehalten.
• Tests: Drop zwischen den Schritten, Duplikate, Reihenfolge nach Schlüssel, Masse redrive.

14) Typische Fehler

Senden an Bus und Schreiben in DB in getrennten Schritten ohne Outbox/Offset-Transaktion.
Consumer ohne Idempotenz dupliziert → Nebenwirkungen.
Eine globale Ordnung „um jeden Preis“ ist teuer und selten gerechtfertigt; Ordnung nach Schlüssel genügt.
Ein Massenredrive ohne Grenzen → ein sekundärer Vorfall.
Mangel an Tracing/Lag-Metriken → „versteckte Degradation“.
Mischen von PII in DLQ/Logs.

15) Schnelle Rezepte

SaaS-Events: Outbox + idempotent consumer (inbox), Partitionierung nach 'tenant _ id: aggregate _ id'.
ETL/Projektionen: Read-process-write mit Fixierung von Offsets in einer Transaktion, Batches 500-1000, upsert.
Hohe Belastung: Sharding Kneipen, 'SKIP LOCKED', WFQ per tenant, Lagekontrolle.
Strenge Compliance-Zone: regionale Outbox, Payload-Verschlüsselung, Retention und Redrive-Audit.

Schlussfolgerung

Transactional Messaging ist die Disziplin der Verbindung von Daten und Nachrichten. Durch die Kombination von Outbox/Inbox, Idempotenz, Offset-Fixierung zusammen mit Effekten und geführten Retrays mit DLQ erhalten Sie ein praktisches Exactly-Once-Verhalten ohne globale Sperren und behalten SLO auch bei Ausfällen, Peaks und anspruchsvollem Multi-Tenant-Betrieb.