Skip to main content

Recruitment Outbox Operations

Purpose​

Explains Pending, Failed, and Processed outbound states without replay instructions.

Confirmed implementation​

Supported domain events are mapped and persisted with the local transaction. The relay polls eligible Pending/Failed rows. Publication success marks Processed; failure marks Failed and increments retry count.

Safe operational guidance​

Inspect business completion, outbox existence/state, retry count, safe correlation reference, and relay logs. Distinguish publication from consumption; no confirmed consumers exist.

Signals and evidence​

Missing row for an unmapped event, persistent Pending/Failed, increasing retries, Processed publication, and absent downstream effect.

Risks and escalation​

Retry ceiling, backoff, dead-letter, replay, poison handling, monitoring, consumer ownership, and approvals require confirmation.

Outbox and dependency operations​

Source References​

  • microservices/src/recruitment-service/Messaging/OutboxRelayHostedService.cs
  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs
  • microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
  • microservices/src/recruitment-service/Api/RecruitmentEndpoints.cs

Summary​

This Draft page summarizes source-backed Recruitment behavior and explicitly marks incomplete governance or implementation.

Audience​

Recruitment stakeholders, product, engineering, QA, support, operations, architecture, security, and implementation partners as applicable to this page.

Overview​

Use the source-backed sections above as the authoritative scope. Unsupported behavior remains Requires confirmation or Not implemented.

See Also​

Keywords​

  • Recruitment
  • Hiring lifecycle
  • Draft documentation

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-16
  • Review cycle: Quarterly