Skip to main content

Data Integrity

Audience​

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

Reference Content​

Summary​

Local integrity combines primary keys, selected uniqueness, configured child relationships, tenant filters, domain validation and idempotency ledgers. Cross-context lifecycle integrity remains eventual and application-owned.

Integrity layers​

Strong local guarantees​

Configured aggregate children and unique business/event identifiers are enforced in their own contexts. Recruitment completion saves its local aggregate, evidence and outbox atomically; Employee does the same for its own aggregate boundary.

Cross-store gaps​

  • Employee creation and Recruitment completion are separate commits.
  • Compatibility and extracted records have no shared constraint.
  • Payroll/Leave/Attendance projections cannot use foreign keys to Employee Service.
  • Asset clearance is not a constraint on exit.
  • Notification delivery is not a constraint on lifecycle completion.

Operational requirement​

A production design needs correlation, replay, duplicate handling, reconciliation ownership and a definition of which store wins after partial failure.

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