Skip to main content

Compatibility and Transition Architecture

Summary

The gateway can select legacy monolith or extracted Recruitment handling for compatibility-shaped Recruitment onboarding traffic. The frontend can therefore keep one interaction model while runtime ownership changes. Offboarding remains on the monolith path.

Audience

Developers, QA, support, security reviewers, release engineers, and solution architects.

Route ownership selection

The compatibility adapter preserves legacy-shaped requests and responses while delegating to extracted commands. It is an anti-corruption boundary, not proof of equivalent internal effects.

Semantic differences

ConcernLegacy monolith completionExtracted compatibility completion
Workforce initializationCreates monolith labor and associated user behaviorEnsures an Employee through Employee Service
Completion payloadPersists more legacy fieldsAccepts compatibility shape but does not consume every field
Login outcomeUser creation behavior is presentLogin remains pending/outside Employee client
Organization mappingMonolith-specific mappingDepartment, designation, manager, and location remain incomplete
PersistenceMonolith databaseRecruitment database plus synchronous Employee call

Transition risks

  • A route-selection change can alter profile completeness and login readiness without a frontend change.
  • Authorization boundaries differ between gateway, extracted endpoints, and mixed monolith Recruitment actions.
  • Legacy and extracted persistence do not provide a shared lifecycle history.
  • Response compatibility can mask different side effects.
  • Rollback to the legacy path does not automatically reconcile records created on the extracted path.

Migration evidence needed

A safe transition requires contract tests, side-effect comparisons, tenant-isolation tests, dual-path smoke coverage, data reconciliation, observability, and an explicit ownership cutover decision. These are requirements inferred from the implementation shape; a completed migration plan was not found.

Requires confirmation

  • Environment-specific route ownership and direct-service exposure.
  • Cutover, rollback, reconciliation, and compatibility retirement criteria.
  • Authoritative employee identity when both paths have processed related records.
  • Required equivalence for profile fields, login, notifications, and downstream events.

Source References

  • microservices/src/gateway-api/Program.cs
  • microservices/src/recruitment-service/Api/RecruitmentCompatEndpoints.cs
  • microservices/src/recruitment-service/Application/Compatibility/CompatCommands.cs
  • microservices/src/recruitment-service/Application/Compatibility/CompatContracts.cs
  • Controllers/RecruitmentController.cs

See Also

Keywords

  • Compatibility routing
  • Migration boundary
  • Semantic parity

Revision Information

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