You have two reasonable ways to build a feature. How do you decide?
Quick Answer
Name the forces that matter here — time-to-ship, change frequency, team familiarity, performance, operational cost — and weigh each option against them. Favour the simpler, more reversible option unless a specific requirement rules it out. If it's genuinely close, timebox a spike, write a short decision record, and move on.
I start by making sure I understand the actual requirement, because a lot of design debates come from an unstated constraint — is this going to 10x, does it need sub-100ms latency, when does it ship. Then I write down the forces that matter for this feature and score both options honestly, including how familiar the team is and how much operational overhead each adds, not just which is prettier. A big factor is reversibility — if it's easy to change later I don't agonise, I pick the simpler one and move on; if it's a one-way door like a data model or a public contract, I slow down. If it's genuinely close I timebox a spike and write a short decision record so the “why” isn't lost.
- Clarify the requirement — half of “which design” questions dissolve once you pin down the actual constraint (scale, latency, deadline).
- List the forces — and which ones actually matter for this feature, not in the abstract.
- Score both against those forces; be honest about team familiarity and operational burden, not just elegance.
- Reversibility — a “two-way door” decision (easy to change later) doesn't deserve much deliberation; a “one-way door” (public API shape, data model, choice of datastore) deserves more.
- Simplicity bias — pick the one you can explain in one sentence and delete later, unless a requirement forces the other.
- Spike + ADR — if still unclear, timebox a prototype, then write a one-page architecture decision record so the reasoning survives.