Architecture Is the Decision You Don't Get to Remake Later

5 MINS

After two decades writing Java/J2EE and designing systems on AWS, I've come to believe that architecture is mostly about anticipating the regret. The best designs aren't the ones that look elegant on a whiteboard. They're the ones that survive the day production breaks at 3 a.m. and someone — possibly you — has to keep the business running.

The blast radius rule

Every architectural decision has a blast radius — the set of things that have to change if you got it wrong. Some decisions have a small blast radius (a class name, a config value). Others quietly dictate the next ten years (a database choice, a service boundary, a deployment topology).

Small blast radius? Just decide. Iterate later. Don't over-think it.

Large blast radius? Slow down. Write the assumptions down. Make sure two other people can argue with them.

Truly irreversible? Get it wrong intentionally — pick the cheapest mistake — before you commit. The mistake I see most often is treating big and small decisions with the same energy. You burn weeks on naming a service that nobody will remember and ship a database migration that turns into the next year's tech debt.

Designing for the first bad day

A useful question I ask myself before every architecture review: what happens on the first bad day? Not the happy path. Not the green dashboard. The day a downstream goes silent, the day a deploy half-applies, the day a bad payload makes it past validation.

If you can answer those, calmly and specifically, your architecture probably holds. If you can't, it's a hope, not a design.

Where does the system fail safely?

Where does it fail loudly?

Where does it fail invisibly? — that one is the dangerous answer The third category is where the next outage lives.

What 24 years has taught me

The frameworks change. The vendors change. The titles change. What stays the same is the discipline: write things down, leave the system better than you found it, and trust the people who actually run it on call.

Architecture isn't a document. It's a contract you make with the people who will inherit your system after you've moved on.

Picking AWS Is Not a Strategy

Manik skipped presentations and built real AI products.

Manik Wadhwa was part of the January 2026 cohort at Curious PM, alongside 13 other talented participants.