Flexible documents still need a domain contract. Database validation can reject shapes that violate required types or fields.
Before you start
You should understand documents, collections and indexes. Sketch representative documents and the reads and writes they must support. MongoDB-specific examples assume a collection with the shown fields; deployment topology, permissions and existing indexes can affect the operational behavior being discussed.
The practical goal is to reason through this situation: Validate an order status and numeric total before accepting writes. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Write the domain shape
Specify required fields, allowed types and meaningful constraints.
Step 2: Align all producers
Application and database validation should support compatible records.
Step 3: Migrate in phases
Backfill and update writers before tightening a newly required field.
Worked scenario
Validate an order status and numeric total before accepting writes.
A new currency field cannot safely become mandatory while older writers still omit it. Start with compatible validation, update producers and existing documents, then tighten enforcement. Flexible storage helps evolution, but does not eliminate the need to know which shapes readers support.
Common mistake
A flexible database does not eliminate application and migration validation.
Verify the behavior
Test old and new records through each migration stage.
Interview exercise
Evolve a required field.
Answer and reasoning
Introduce compatible validation rules, backfill existing records and tighten enforcement after producers support the new contract.
Continue learning
Compare the scenario with the MongoDB interview questions and test your understanding with the MongoDB MCQs. For terminology and implementation details, consult the reference material.