Skip to main content

Employee Data Consistency and Reconciliation

Summary​

The monolith and extracted service maintain separate Employee models and identifier families; no historical backfill runner or durable cross-model identifier map was found.

Audience​

  • Service/database owners, DevOps/support engineers, QA engineers, and architects

Coexistence boundary​

The monolith compatibility UI uses numeric employee identifiers and a broad DTO. Employee Service owns GUID aggregate identifiers and a separate tenant-scoped schema. Its compatibility endpoints reject numeric Legacy identifiers instead of manufacturing mappings.

Risks and expectations​

Duplicate or partial records, divergent active state, missing organization references, stale UI projections, and incomplete downstream events are plausible transition risks. No source establishes dual-write, continuous reconciliation, conflict authority, historical backfill, or a durable ID map.

Safe investigation​

Identify route source and identifier family; compare sanitized counts and stable business keys using approved read-only tools; confirm tenant scope; correlate request time with logs and migration/outbox state; and involve both data owners before any remediation. Direct production editing is prohibited by this guide.

Ownership​

Source-of-truth selection, reconciliation thresholds, exception approval, and repair tooling Require confirmation from product, Employee Service, monolith, database, and gateway owners.

Source References​

  • microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
  • microservices/src/employee-service/Api/EmployeeCompatibilityEndpoints.cs
  • microservices/src/employee-service/docs/employee-compatibility-placeholders.md
  • Data/AppDbContext.cs

See Also​

Keywords​

  • data reconciliation
  • identifier coexistence
  • backfill gap

Revision Information​

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