Attendance Outbox and Delivery
Summary
The outbox closes the atomicity gap between Attendance state and durable intent to publish; it does not make consumer processing transactional with Attendance.
Audience
- Backend developers, DevOps engineers, support engineers, QA engineers, and architects
Confirmed behavior
An outbox row stores message identity, unique event identity, event type, serialized contract, occurrence time, processing state, processed time, retry count, bounded error text, correlation, tenant envelope context, and source service. Schema version is contained in the serialized shared contract.
The hosted relay polls pending and failed rows in occurrence order, publishes a bounded batch, and marks each processed or failed. Broker publication uses persistent messages and event-type routing. Exact topology is intentionally omitted.
The Attendance relay has retry-through-repolling but no confirmed terminal attempt limit or Attendance-owned dead-letter store. Monitoring is based on outbox status, retry count, error state, and logs; a dedicated Attendance event-delivery dashboard or replay API is Not implemented.
A processed outbox row means the publish call succeeded. It does not prove broker retention, a consumer acknowledgement, projection update, notification delivery, or end-to-end business completion.
Source References
microservices/src/attendance-service/Infrastructure/AttendanceDbContext.csmicroservices/src/attendance-service/Infrastructure/Persistence.csmicroservices/src/attendance-service/Infrastructure/OutboxRelayHostedService.csmicroservices/src/shared-kernel/Outbox/OutboxMessage.csmicroservices/src/shared-kernel/Messaging/OutboxProcessor.cs
Related Articles
See Also
Keywords
- Attendance events
- Integration contracts
- Eventual consistency
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly