Skip to main content

Persistence Architecture

Audience​

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

Reference Content​

Summary​

Each runtime owns a local EF Core context. Cross-context coordination occurs through synchronous service calls, integration events, compatibility routing or manual operations; it does not occur through database joins.

Architecture​

Save and delivery model​

  • A Recruitment completion first invokes Employee Service and later saves Recruitment completion, candidate stage, audit, timeline and outbox state together.
  • Employee aggregate changes, local evidence and outbox intent share an Employee-context save.
  • Consumer-owned projections are written in the consumer's local transaction.
  • Compatibility controllers save lifecycle state directly through the compatibility context.
  • Notification delivery state and processed-event state are local to Notification Service.

Boundary rule​

A local commit proves only that context's state. It does not prove downstream readiness, notification delivery, asset clearance or a globally completed lifecycle.

Not implemented​

No shared transaction coordinator, database-level cross-context foreign key, dual-write reconciler or canonical cross-context lifecycle checkpoint was found.

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