hybrid-cloud-outboxes

Sentry uses a transactional outbox pattern for eventually consistent operations. When a model changes, an outbox row is written inside the same database transaction. After the transaction commits, the outbox is drained — firing a signal that triggers side effects such as RPC calls, tombstone propagation, or audit logging.

The most common use case is cross-silo data replication: a model saved in the Region silo produces a RegionOutbox that, when processed, replicates data to the Control silo (or vice versa via ControlOutbox). But the pattern is general — outboxes work for any operation that should happen reliably after a transaction commits, even within a single silo.

There are two outbox types corresponding to the two directions of flow:

Leitfaden zum Erstellen und Verwalten postausgangsbasierter, eventuell konsistenter Vorgänge in Sentry. Wird am häufigsten für die siloübergreifende Datenreplikation verwendet, kann aber überall dort eingesetzt werden, wo eventuelle Konsistenz erforderlich ist – einschließlich verzögerter Nebenwirkungen für einzelne Silos, Audit-Protokollierung und Ereignis-Fanout. Wird verwendet, wenn Sie aufgefordert werden, „Postausgang hinzufügen“, „Postausgangsreplikation hinzufügen“, „Modell zur Steuerung des Silos replizieren“, „Modell in Region replizieren“, „Postausgangskategorie hinzufügen“, „Postausgangssignalempfänger schreiben“, „steckengebliebene Postausgänge debuggen“, „Postausgang wird nicht verarbeitet“, „Daten werden nicht repliziert“, „Postausgang testen“, „Modell zur Verwendung von Postausgangsdaten migrieren“, „Postausgangsdaten auffüllen“, „Postausgangszusammenführung“, „ReplicatedRegionModel“, „ReplicatedControlModel“ „OutboxCategory“, „OutboxScope“ oder „outbox_runner“. Behandelt Modell-Mixins, Kategorieregistrierung, Signalempfänger, Test-, Backfill- und Debugging-Workflows. Quelle: getsentry/sentry.