Leave Outbox and Delivery
Summary
The Leave outbox atomically records integration intent with one SaveChanges commit; broker publication and all consumer outcomes remain outside that commit.
Audience
Developers, QA, architects, operations/support, and messaging owners.
Concept
The outbox records message/event identity, event type, serialized contract, occurrence and processing time, state, retry/error information, optional correlation/tenant context, and source service. Schema version is in the serialized contract; the relay metadata builder does not explicitly add it to broker headers. Payload bodies and exact topology are outside this public guide.
The relay requests bounded oldest-first Pending/Failed batches, publishes persistent broker messages through shared infrastructure, then marks each row processed or failed. Failed rows remain eligible on later polls; no Leave-specific terminal attempt limit, dead-letter transition, or replay operator workflow was found. Monitoring exposes logs but no source-confirmed Leave outbox backlog metric or consumer-completion acknowledgement.
Processed means the shared publisher reported success and the row was updated. It does not guarantee broker routing, consumer processing, downstream persistence, or notification delivery. Multi-save request/balance flows produce independent atomic boundaries.
Source References
- microservices/src/leave-service/Infrastructure/LeaveDbContext.cs
- microservices/src/leave-service/Infrastructure/Persistence.cs
- microservices/src/leave-service/Messaging/OutboxRelayHostedService.cs
- microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
- microservices/src/shared-kernel/Messaging/RabbitMqEventBus.cs
- microservices/src/shared-kernel/Outbox/OutboxMessage.cs
Related Articles
See Also
Keywords
- Outbox atomicity
- Relay delivery
- Eventual consistency
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly