SQL or NoSQL — Defend the Choice
mediumTrade-off callVery commonly asked~10 minHLD roundHiring managerBar raiserSDE-2 and upAmazonMicrosoftAtlassianRazorpayFlipkartStorage & Data ModellingConsistency & Consensus
The question, as asked
“You picked that database. Why not the other one? Talk me through when you'd switch.”
Scope it before you design it
The prompt is vague on purpose. These are the clarifying questions a strong candidate asks first — answer them out loud before you touch the architecture.
- What are the actual queries? This is the only question that matters. 'What data do we store' tells you almost nothing; 'how is it read' decides everything.
- Are the access patterns known and stable, or will product invent new queries every sprint? Known patterns favour a key-value store; unknown ones favour SQL.
- Does anything need a multi-row transaction? Money movement, inventory and booking all do, and that constraint alone usually ends the discussion.
- What's the real write volume? Most people quote a number that a single Postgres instance would handle without noticing.
- How relational is the data really? Ask whether you'd ever need to join across entities in a way you can't predict today.
- What does the team already run? An unfamiliar database in production is a reliability risk that rarely appears on the comparison table.
Your answer, first
Commit something before anything unlocks. Saved on this device as you go.
0 charactersExpand for room to draw
Framework hint
Sketch or write your approach above first. The hint gives you the structure, not the answer.