Skip to main content

Leave Data Consistency and Reconciliation

Summary​

Monolith and Leave Service coexistence creates confirmed divergence risk across requests, balances, profiles, calendars, workflow state, and downstream projections.

Audience​

Support, service/data owners, QA, architects, and product owners.

Overview​

Reconcile by comparing source-authorized, tenant-scoped evidence for:

  • request identity, dates, status, and latest transition;
  • balance components and derived available value;
  • Employee projection identity, active state, joining date, and freshness;
  • holiday/weekly-off calendar ownership;
  • Payroll read-model reflection after confirmed events;
  • Workflow correlation and terminal state;
  • gateway-selected ownership and compatibility response.

Use counts, safe identifiers, timestamps, correlation identifiers, and statuses. Do not copy reasons, personal data, payload contents, or configuration values. Do not directly update either database.

No universal automated reconciliation tool or authoritative dual-write repair procedure was found. Escalate divergence to both owning services and the relevant business owner.

Source References​

  • microservices/src/leave-service/Application/LeaveWorkflows.cs
  • microservices/src/leave-service/Messaging/EmployeeProfileConsumer.cs
  • microservices/src/payroll-service/Messaging/PayrollReadModelConsumer.cs
  • microservices/src/gateway-api/Program.cs

See Also​

Keywords​

  • Leave operations
  • Leave Data Consistency and Reconciliation
  • Service support

Revision Information​

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