Skip to main content

Concurrency and Idempotency

Audience​

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

Reference Content​

Summary​

No row-version, timestamp or explicitly configured optimistic concurrency token was found in the inspected lifecycle mappings. Concurrency safety relies on application checks, uniqueness and event idempotency.

Protection mechanisms​

  • Unique compatibility/business identifiers reduce duplicate aggregate creation.
  • Processed-event uniqueness protects consumers that persist such a ledger.
  • Outbox event identity protects duplicate publication intent in configured contexts.
  • Repository state checks make some commands idempotent.

Race model​

Risks​

Parallel completion, approval/rejection, rollback/access revoke or assignment updates may observe stale state. Unique constraints address duplicates, not conflicting valid updates. Cross-context retries can also replay after partial success.

Open concurrency questions​

Expected conflict behavior, isolation level, retry policy, command idempotency keys and operator resolution procedures require explicit design and tests.

Requires confirmation​

Unless explicitly confirmed above, production migration governance, rollback, reconciliation, retention, privacy, performance, concurrency and operational ownership require confirmation.

Source References​

  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs
  • microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
  • Data/AppDbContext.cs

See Also​

Keywords​

  • Onboarding database
  • Offboarding database
  • Lifecycle persistence

Revision Information​

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