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:

Guía para crear y mantener operaciones eventualmente consistentes basadas en la bandeja de salida en Sentry. Se utiliza más comúnmente para la replicación de datos entre silos, pero se aplica en cualquier lugar donde se necesite coherencia, incluidos los efectos secundarios diferidos en un solo silo, el registro de auditoría y la distribución de eventos. Úselo cuando se le solicite "agregar bandeja de salida", "agregar replicación de la bandeja de salida", "replicar el modelo para controlar el silo", "replicar el modelo a la región", "agregar categoría de la bandeja de salida", "escribir receptor de señal de la bandeja de salida", "depurar bandejas de salida atascadas", "la bandeja de salida no se procesa", "los datos no se replican", "probar la bandeja de salida", "migrar el modelo para usar las bandejas de salida", "rellenar los datos de la bandeja de salida", "unir la bandeja de salida", "ReplicatedRegionModel", "ReplicatedControlModel", "OutboxCategory", "OutboxScope" o "outbox_runner". Cubre mixins de modelos, registro de categorías, receptores de señales, pruebas, reabastecimiento y flujos de trabajo de depuración. Fuente: getsentry/sentry.