How we review an architecture

The situation

A platform that had been built quickly and built reasonably well, but had never been assessed as a whole. The team could describe individual decisions, but nobody could answer a direct question about whether the overall architecture was sound.

What we did

A structured review covering reliability, security, operational practice, performance, and cost — run as working sessions with the engineers who owned each part of the system, rather than an audit performed on them.

What we typically find

• A critical data store with no tested failover, where backups exist but have never been restored to confirm they work.
• Access permissions granted broadly during an early integration and never narrowed afterward.
• No documented procedure for the most common failure mode, with recovery depending on one specific person.
• Compute running without the reserved-capacity coverage a stable workload would justify.

What we recommended against

Not every finding is worth acting on. In one review, a multi-region active-active setup was technically indicated but wrong for the business — the added cost and operational complexity far exceeded the value at that scale, and a simpler change already addressed the actual risk. In another, a proposal to break apart a well-understood, working service was set aside: it wasn't the constraint, and rebuilding it would have consumed significant time for no measurable benefit. Saying so plainly is part of the review, not an afterthought.

Result

A ranked list of what actually needs attention, evidence that the highest-risk issues have been addressed, and a documented rationale for the ones that were deliberately left alone.