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:

Guide pour créer et maintenir des opérations finalement cohérentes basées sur la boîte d'envoi dans Sentry. Le plus souvent utilisé pour la réplication de données entre silos, mais applicable partout où une cohérence éventuelle est nécessaire, y compris les effets secondaires différés d'un seul silo, la journalisation d'audit et la diffusion des événements. À utiliser lorsqu'on vous demande de "ajouter une boîte d'envoi", "ajouter une réplication de la boîte d'envoi", "répliquer le modèle pour contrôler le silo", "répliquer le modèle dans la région", "ajouter une catégorie de boîte d'envoi", "écrire le récepteur du signal de la boîte d'envoi", "déboguer les boîtes d'envoi bloquées", "la boîte d'envoi ne traite pas", "les données ne sont pas répliquées", "tester la boîte d'envoi", "migrer le modèle pour utiliser les boîtes d'envoi", "remplir les données de la boîte d'envoi", "coalescence de la boîte d'envoi", "ReplicatedRegionModel", "ReplicatedControlModel", "OutboxCategory", "OutboxScope" ou "outbox_runner". Couvre les mixins de modèles, l'enregistrement des catégories, les récepteurs de signaux, les workflows de test, de remplissage et de débogage. Source : getsentry/sentry.