Topic 8.8
Document Databases
In one line
MongoDB-style: JSON documents, embedded nesting, flexible schema, secondary indexes, and Atlas-scale ops.
Think of it like this
A folder that holds a person's entire profile in one page — photo, address, and recent orders all stapled together — so you grab the whole thing in one pull instead of digging through five different filing cabinets.
Key ideas
- 01
Unit of storage: a document (JSON/BSON) — related data embedded together → one read, no join.
- 02
Embed vs reference: embed when read-together & bounded growth; reference when shared / unbounded (comments on a post).
- 03
Indexes: single-field, compound, and text; schema flexibility means index discipline is on YOU.
- 04
Transactions: single-document atomic; multi-document transactions exist (4.0+) but cost and scale poorly — design around them.
- 05
Horizontal scale: shard by shard key; hot documents are a real problem (8.5) in document stores too.
- 06
Interview framing: 'profile with orders embedded' is the canonical happy case; 'billions of events' is not.
Java / Spring map
- →
Spring Data MongoDB: @Document, MongoTemplate aggregate pipelines, DBRef for references.
Explain without notes
Orders embedded inside a user document: when does that become a bad idea? Name two symptoms.
Practice
Model a notification-preference profile as a document and justify embedding vs referencing.
Trade-offs
- ↔
Flexible schema = schema drift debt; the team becomes the schema. Pin it in review.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can embed-or-reference with the read-together + growth rules in hand.