Recruitment Data Integrity and Transactions
Summary
Local Recruitment changes, queued audit/timeline evidence, and outbox intent commit through explicit SaveChanges boundaries; external effects are not atomic with them.
Audience
Developers, QA and support engineers, data reviewers, implementation partners, solution architects, and security reviewers.
Overview
Confirmed integrity
- Every persisted object has a primary key.
- Eight configured child relationships use cascade delete.
- Ten unique indexes enforce compatibility/token/event identities.
- Required/max-length mappings and enum conversions provide database mapping constraints.
- Candidate name and offer compensation are owned by their aggregate rows.
- No concurrency token or optimistic-concurrency handler is configured.
EF SaveChanges provides the local transaction for tracked state. Some commands use multiple saves around Workflow interaction. Document storage and Employee provisioning can occur before local commit; Workflow and broker activity also cross the local boundary. No distributed transaction, saga persistence, compensating-write store, or reconciliation queue is implemented.
Many cross-root identifiers are logical rather than foreign keys, and duplicate-application prevention is application behavior rather than a unique constraint.
Requires confirmation
Production migration governance, rollback ownership, reconciliation, retention, privacy, performance, query optimization, concurrency, and operational ownership require confirmation.
Source References
microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.csmicroservices/src/recruitment-service/Infrastructure/Persistence.csmicroservices/src/recruitment-service/Application/Commandsmicroservices/src/recruitment-service/Messaging/OutboxRelayHostedService.cs
Related Articles
See Also
Keywords
- Recruitment database
- Integrity and Transactions
Revision Information
- Status: Draft
- Last reviewed: 2026-07-16
- Review cycle: Quarterly