Question 3 / 50
MongoDB is schema-flexible. When does that help, and when does it hurt?
Short answer
It helps while a shape is still changing, and for genuinely heterogeneous documents. It hurts once several services read the same collection, because the schema then lives in application code instead of in one place.
Why?
A migration can be a background backfill rather than a locking DDL change. The cost is that every reader has to defend against older shapes. Teams re-introduce guarantees on purpose: collection validation, a version field, and a single owning service. Saying MongoDB has 'no schema' is wrong — the schema is just enforced somewhere else.
Interview tip
Treat flexibility as a design decision with a cost, not as a free feature.
Common mistake
Using flexible schema as an excuse to skip validation, then surprising the API with missing fields in production.
How did you do?
Cheat Sheet