You must choose a data store this week. The product team cannot tell you the expected query patterns or the growth rate. What do you do?

What the interviewer is testing

How you behave when the information you would like does not exist — which is the normal condition, not the exception. Both "refuse to decide" and "decide confidently on nothing" are failures.

The moves, in order

1. Establish what kind of door this is. A data store choice is close to a one-way door: schema, query patterns and operational knowledge all accrete around it. That means it deserves the effort below rather than a coin flip — but also that the most valuable property right now is optionality, not optimality.

2. Buy the cheapest information available first. Not a six-week analysis — a day. Look at the screens already designed, since they imply queries. Look at a comparable system in the estate. Ask the product team a different question: not "what are your query patterns" (which they cannot answer) but "what will users be looking at, and what will they filter by" (which they can).

3. Choose the option that is wrong least expensively. With unknown access patterns, the dominant risk is being locked into a store that cannot answer a question you have not thought of yet. That argues strongly for a relational database: ad-hoc queries, joins, secondary indexes added later, and strong transactional guarantees. It is the option whose failure mode is "slower than ideal" rather than "cannot do this at all". A key-value store chosen for scale, queried relationally later, is the expensive mistake here.

4. Preserve reversibility deliberately. Keep data access behind a repository boundary so the store is not named throughout the codebase. Avoid vendor-specific features until they earn their place. Keep the schema conservative.

5. Write down what would change the decision. "If sustained write throughput exceeds X, or the dataset exceeds Y, or access becomes single-key at high volume, revisit." That converts an uncertain decision into a monitored one.

6. Record it as an ADR, with the context — including that the query patterns were unknown at the time. In eighteen months this is what stops a colleague concluding the choice was careless.

What not to do

Do not escalate for a decision the product team genuinely cannot make. Do not pick the most flexible possible option by adding three stores "to cover the cases". Do not wait — the decision has a deadline and deferring it past that is a decision to have nothing.

What a strong answer adds

Naming the asymmetry explicitly: under uncertainty, prefer the option with the best worst case rather than the best expected case. And noting that the discipline generalises — most architecture decisions are made with roughly this much information, and the ones that go badly are usually the ones where nobody wrote down what would have changed their mind.