Why this matters
- VaultCommerce product catalogs vary wildly: electronics have specs, apparel has sizes, groceries have expiry dates — a rigid SQL schema fights every new category.
- Interviewers ask when you'd trade joins for embedded documents and what consistency you give up.
- MongoDB is the most common document store in production Java shops; knowing its access patterns prevents expensive redesigns.
When documents beat tables
VaultCommerce started with Postgres for orders and inventory. Product pages, however, needed nested attributes, locale-specific copy, and review snippets loaded in a single round trip. That access pattern maps naturally to documents.
Document store strengths
- Flexible schema — add
warranty_monthsto electronics withoutALTER TABLE. - Embedded data — reviews, variants, and images live inside the product document.
- Horizontal scale — shard by
category_idorseller_idwhen catalogs grow. - Developer ergonomics — JSON maps directly to API responses.
{
"_id": "prod_8842",
"name": "VaultCommerce Noise-Cancelling Headphones",
"category": "electronics",
"price": { "amount": 14999, "currency": "INR" },
"variants": [
{ "sku": "VC-HP-BLK", "color": "black", "stock": 240 },
{ "sku": "VC-HP-WHT", "color": "white", "stock": 87 }
],
"reviews": [
{ "user_id": "u_12", "rating": 5, "text": "Battery lasts all day." }
]
}
Modelling for your queries
Design documents around read paths, not entity diagrams. VaultCommerce's product detail API needs one findById; the admin bulk-export needs a different shape — sometimes a separate collection is cleaner than one mega-document.
// Primary read path — single document fetch
db.products.findOne({ _id: "prod_8842" })
// Category browse — index on category + sort field
db.products.find({ category: "electronics" })
.sort({ "metrics.sales_rank": 1 })
.limit(24)
Indexing and consistency
MongoDB indexes work like B-trees on document fields. Compound indexes must match query sort order. Multi-document ACID transactions exist but add latency — VaultCommerce keeps financial writes in Postgres and uses MongoDB for catalog reads with occasional eventual consistency on review counts.
| Concern | MongoDB approach | VaultCommerce choice |
|---|---|---|
| Primary reads | Replica set with read preference | Primary for inventory sync jobs |
| Unbounded arrays | 16 MB document limit | Paginate reviews in separate collection |
| Schema drift | Validation rules on collection | JSON Schema enforced at write |
| Cross-document joins | $lookup aggregation | Avoid — denormalise hot fields |
Primary reads
MongoDB approachReplica set with read preferenceVaultCommerce choicePrimary for inventory sync jobsUnbounded arrays
MongoDB approach16 MB document limitVaultCommerce choicePaginate reviews in separate collectionSchema drift
MongoDB approachValidation rules on collectionVaultCommerce choiceJSON Schema enforced at writeCross-document joins
MongoDB approach$lookup aggregationVaultCommerce choiceAvoid — denormalise hot fields
When not to use MongoDB
Orders, payments, and inventory adjustments need strict multi-row transactions. VaultCommerce never moved checkout to MongoDB. Document stores shine for read-heavy, shape-varying data — not for ledger-grade consistency.
Quick recall
Everything you need if you only revisit this box.
- Documents match nested, read-heavy access patterns — one fetch per product page.
- Model for queries first; embed when data is read together, reference when it grows without bound.
- VaultCommerce keeps transactions in Postgres and catalogs in MongoDB.
- Index compound fields in the same order as your
find().sort()queries. - Document flexibility does not remove the need for schema discipline.
Test yourself
Answer these before moving on — recall is what makes it stick.