Employee Outbox Operations
Summary
Employee mutations can stage integration messages transactionally, but Employee Service has no confirmed runtime invoker for the registered outbox processor.
Audience
- Employee/messaging owners, DevOps/support engineers, QA engineers, and architects
Operational concepts
Pending records await processing; failed records remain eligible and carry retry/error state; processed records record completion. The shared processor publishes eligible messages and changes these states when called.
Visibility and monitoring
Approved read-only observability should report counts/age by safe status, repeated failures, and processing progress without logging payloads. No Employee dashboard, backlog metric, alert threshold, or hosted relay was found. Monitoring and relay ownership Require confirmation.
Safe escalation and replay restrictions
Collect service version, sanitized event type/identifier, occurrence window, status/retry category, correlation identifier when present, and whether any processor is actually invoked. Do not copy payloads or run ad hoc replay/data-update commands. Replay requires authorization, consumer idempotency review, and messaging/database owner coordination.
Source References
microservices/src/employee-service/Infrastructure/EmployeeDbContext.csmicroservices/src/employee-service/Infrastructure/Persistence.csmicroservices/src/employee-service/Program.csmicroservices/src/shared-kernel/Messaging/OutboxProcessor.cs
Related Articles
See Also
Keywords
- outbox backlog
- relay ownership
- safe replay
Revision Information
- Status: Draft
- Last reviewed: 2026-07-15
- Review cycle: Quarterly