Skip to main content

Recruitment Event Idempotency and Ordering

Summary​

Event identity and persistence constraints support deduplication foundations, but Recruitment has no inbound processor and provides no ordering guarantee.

Audience​

Developers, QA and support engineers, integration reviewers, implementation partners, solution architects, and security reviewers.

Overview​

Domain and integration identities are distinct. The outbox enforces unique integration event identity. The processed-event ledger has a unique event identity but no registered Recruitment consumer writes it.

The relay orders eligible records by occurrence time, but equal-time behavior, concurrent relays, broker ordering, partitioning, per-candidate ordering, global ordering, and replay ordering are not defined. Workflow callbacks, public terminal offer responses, onboarding completion, and Employee provisioning have application-specific retry/idempotency checks; these are not exactly-once event processing.

Requires confirmation​

Consumer ownership, tenant-envelope policy, correlation/causation policy, retry limits, replay, ordering, contract governance, reconciliation, monitoring, and production support require confirmation.

Source References​

  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs
  • microservices/src/recruitment-service/Infrastructure/Persistence.cs
  • microservices/src/recruitment-service/Application/Commands/RequisitionCommands.cs
  • microservices/src/recruitment-service/Application/Commands/OfferCommands.cs
  • microservices/src/recruitment-service/Application/Commands/OnboardingCommands.cs
  • microservices/src/recruitment-service/Infrastructure/EmployeeServiceClient.cs

See Also​

Keywords​

  • Recruitment events
  • Idempotency and Ordering

Revision Information​

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