Most teams ask for an architecture review when they are about to do something large and irreversible — a rewrite, a platform migration, a split into services. They want a second pair of eyes before they commit a quarter of engineering to it. That is the right instinct, and it is almost never the review that helps most.
The review that helps most is the one you ask for when nothing is on fire and nothing is planned. When you simply want someone with no stake in the current design to read the system and tell you what it actually does, as opposed to what the original design document said it would do.
When to ask for one
There are three moments when a review pays for itself.
The first is before a rewrite. A rewrite is a bet that the new system will be easier to change than the old one. That bet is only good if you understand why the old one became hard to change, and most teams do not — they have a story about it, but the story is usually wrong in a specific, expensive way.
The second is after a string of incidents that each looked unrelated. When the post-mortems keep landing in different services but the underlying cause keeps rhyming, there is usually one structural fact connecting them. Finding it is reading work, not debugging work.
The third is when a senior engineer leaves and takes the model of the system with them. The code is still there. The reason it is shaped that way is not.
What we actually do
We read. For the first week we mostly read, in a specific order: the entry point of the surface you care about, then outward along the paths real requests take, then the last six months of incidents and what changed after each one.
- Read the code along the request path, not module by module.
- Read every incident write-up since the last calendar quarter.
- Talk to four to six engineers individually, each for an hour, asking the same three questions.
- Trace one real, important request end to end, logging every hop, including the hops nobody mentions.
- Write the system down in a single document, in your team's own vocabulary.
we should probably just rewrite this is the sentence we hear in week one of almost every engagement. By week three, in most of them, the rewrite is off the table, because the actual problem turned out to be small and specific once it was named.
What you get at the end
A document. Not a slide deck, not a diagram of a future state — a written map of the present one, with the failure modes marked.
The map is useful in two ways. If your team reads it and agrees, the next steps are usually obvious — the document has already done the hard part. If your team reads it and disagrees, the conversation that follows is the most valuable one they will have that quarter, because it is the first time the disagreement has been about the same concrete thing.
If you cannot write the system down in a paragraph, the system is not finished — it is just running.
When it is the wrong call
A review is the wrong call when the team already knows exactly what is wrong and simply lacks the time to fix it. In that case you do not need a map; you need hands, and we would rather do a fix-it engagement.
It is also the wrong call when the real problem is organisational — when the system is fine but the ownership is not. We will tell you when we find that, and then we will stop, because org work is not what we do.