Skip to main content

Recruitment Database Compatibility and Transition

Summary​

Native and compatibility APIs share the same Recruitment persistence model; compatibility identities bridge existing numeric contracts.

Audience​

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

Overview​

Six aggregate roots have database-generated numeric compatibility identities with global unique indexes. Compatibility commands and queries translate to the same repositories and DbContext used by native APIs; there is no separate compatibility store.

Public resume behavior resolves Recruitment document references and delegates bytes to Document Service. Compatibility reads commonly use no-tracking queries. No Recruitment backfill helper, database parity comparator, general upsert engine, or rollback data synchronizer was found. Application-level deterministic Employee provisioning is not a database upsert.

Gateway rollback can restore route ownership but does not reverse or reconcile data written while Recruitment Service owned the route. Transitional cutover and reconciliation ownership require confirmation.

Requires confirmation​

Production migration governance, rollback ownership, reconciliation, retention, privacy, performance, query optimization, concurrency, and operational ownership require confirmation.

Source References​

  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs
  • microservices/src/recruitment-service/Infrastructure/Persistence.cs
  • microservices/src/recruitment-service/Application/Compatibility/CompatCommands.cs
  • microservices/src/recruitment-service/Application/Compatibility/CompatQueries.cs
  • microservices/src/gateway-api/Program.cs

See Also​

Keywords​

  • Recruitment database
  • Compatibility and Transition

Revision Information​

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