A team proposes a document database for an order management system because "orders are documents". Assess.

What the interviewer is testing

Whether you choose a datastore on access patterns and consistency requirements rather than on how the data looks.

Why "orders are documents" is not the argument

The shape of one record says very little. What matters is what the system does with the records.

Orders are, in fact, an unusually poor fit for the document-store argument, because order management has the characteristics relational databases are built for:

Multi-entity invariants. An order affects inventory, customer credit and payment state. Enforcing consistency across them wants transactions.

Analytical queries across records. Revenue by region by period, orders containing a given product, customers with more than N orders. These are ad hoc joins and aggregations, which is precisely what a document model makes awkward.

Referential integrity. An order line referring to a product that must exist.

Reporting and downstream integration, which is easier from a normalised model.

Where the document argument would hold

Schema variability — if orders genuinely differ structurally by type in ways a relational schema would model as many nullable columns or an entity-attribute-value table.

Scale beyond a single writer, where horizontal partitioning is required and the access pattern is overwhelmingly by order id.

Read pattern is always the whole aggregate, retrieved by key, with no cross-record querying.

The response

Ask for the access patterns: what queries run, at what rate, with what consistency requirement, at what volume. That conversation settles it in twenty minutes, and it usually lands on a relational database — possibly with a JSON column for the genuinely variable parts, which gets both properties without a second datastore.

What a strong answer adds

Noting that modern relational databases support JSON documents with indexing, so the choice is frequently not binary. And that this is a one-way door — the data model in a system with millions of records and many consumers is expensive to change — which justifies spending time on it now.

Common weak answers

Choosing relational by default without asking about access patterns. Accepting the document argument on record shape.