Recruitment Application Storage

Summary

Candidate applications are candidate-owned records with candidate and logical opening identifiers.

Audience

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

Overview

CandidateApplication has its own primary key, TenantId, CandidateId, JobOpeningId, source, and application time. CandidateId is a configured foreign key to Candidate with cascade delete. JobOpeningId is a logical reference without an EF relationship.

Indexes support CandidateId lookup and tenant/opening lookup. No unique constraint prevents multiple persisted application rows for the same candidate/opening pair; duplicate prevention is application/repository behavior.

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.cs
• microservices/src/recruitment-service/Domain/Recruitment/Candidate.cs
• microservices/src/recruitment-service/Infrastructure/Persistence.cs

Related Articles

• Recruitment database documentation
• Data integrity and transactions

See Also

• Recruitment technical documentation
• Recruitment API documentation

Keywords

• Recruitment database
• Application Storage

Revision Information

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