There's no such thing as the right architecture. There's only the right architecture for this problem, this team, this moment — and the trade-offs you chose on purpose.
When I design a system, I try to resist the urge to draw the boxes first. The boxes are easy. The hard part is understanding what the system is really for, and what we're willing to give up to get it.
Both perspectives, not just the technical one
Good decisions come from understanding the technical and the business side. A design that's elegant but ignores how the company actually makes money — or how the team actually works — isn't elegant. It's a liability with nice diagrams.
So I ask the unglamorous questions early. What has to be true for this to matter in a year? What are we optimising for — speed now, or flexibility later? Who maintains it when I've moved on?
Make the trade-off explicit
The worst trade-offs are the ones nobody noticed they were making. "We'll just cache it" is a decision about staleness. "We'll add a queue" is a decision about complexity and failure modes. Naming the cost out loud is what turns an accident into a choice.
I'm not trying to find the cleverest design. I'm trying to find the one that stays effective long after the initial implementation — the one I can still defend in two years, when the context has changed and I've forgotten why I did half of it.
A decision you can explain is a decision you can revisit. That's most of the value.