Question presented to candidate: "You are picking the main database for a new service. Walk me through how you would decide between a relational SQL database and a NoSQL store. What does each give you, what does each cost you, and can you give me a concrete case where you would pick each one?"
What a strong answer should cover:
- The decision is driven by access patterns, consistency needs and scale, not by fashion: SQL gives a fixed schema, joins, ad-hoc queries and multi-row ACID transactions; NoSQL trades some of those for a data model shaped around known queries and easier horizontal scaling
- "NoSQL" is four different families โ key-value, document, wide-column, graph โ each with its own sweet spot
- Normalization vs denormalization: one fact in one place (cheap updates, joins on read) vs data embedded where it is read (one read, many writes on change)
- Sharding: NoSQL stores are usually built around a partition key, so single-key reads hit one node; normalized tables spread one page across shards
- The lines have blurred: PostgreSQL has JSONB, MongoDB has multi-document transactions (replica sets since 4.0, sharded clusters since 4.2), DynamoDB has
TransactWriteItems(up to 100 actions) โ and most real systems use polyglot persistence - A sane default: start relational unless a specific, measured need (write volume, a key-only access pattern, a graph traversal) says otherwise
Clarifying questions expected:
- What are the main read and write queries, and how many per second at peak?
- Which operations must be atomic across several records (money, stock, bookings)?
- Are the queries known up front, or will analysts ask new questions later?
Code / implementation expected: No โ a reasoned comparison with examples is enough; the example measures the trade-offs on one in-memory data set.