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:

Руководство по созданию и поддержке согласованных операций на основе исходящих сообщений в Sentry. Чаще всего используется для репликации данных между хранилищами, но применим везде, где требуется конечная согласованность, включая отложенные побочные эффекты для одного хранилища, ведение журнала аудита и разветвление событий. Используйте, когда вас просят «добавить исходящий ящик», «добавить репликацию исходящего ящика», «реплицировать модель для управления хранилищем», «реплицировать модель в регион», «добавить категорию исходящих ящиков», «записать приемник сигнала исходящих сообщений», «отладить застрявшие исходящие ящики», «исходящие ящики не обрабатываются», «данные не реплицируются», «тестировать исходящие ящики», «перенести модель для использования исходящих ящиков», «обратное заполнение исходящих данных», «объединение исходящих ящиков», «RelatedRegionModel», «RelatedControlModel», «OutboxCategory», «OutboxScope» или «outbox_runner». Охватывает примеси моделей, регистрацию категорий, приемники сигналов, тестирование, заполнение и рабочие процессы отладки. Источник: getsentry/sentry.