The Architecture Review Every Growing Team Needs

Keep it to a service dependency map showing what calls what and what happens if any one piece goes down, the handful of highest-risk single points of failure, and current known technical debt with an honest owner and a rough cost estimate attached. Leave out a full inventory of every library version; that belongs somewhere else. The test is whether a new senior engineer would find it enough to be genuinely dangerous, in a good way, on day one.

Pull it from something real: your tracing tool's service map if you already have distributed tracing, or a quick direct survey of each service owner about what their service calls and what calls it if you don't. A dependency map assembled from memory in a single meeting is wrong within a month; one grounded in actual traffic or explicit code-level imports stays honest for much longer.

Not every dependency carries equal risk. Ask specifically what happens to the rest of the system if each service goes down for an hour, and rank the list by blast radius, not by how old or unpolished the underlying code happens to look. The answer is often surprising: a small utility service nobody thinks twice about turns out to be a hard dependency for half the product.

For example, a team ranks its services by blast radius and finds that an internal notification service, considered minor, is called synchronously by both login and checkout. If it goes down for an hour, users cannot sign in. That result moves it from an afterthought to the top of the single points of failure list. A common mistake is ranking by how messy the code looks instead of by what breaks downstream. The decision rule: for each service, write one sentence describing what users can no longer do when it is down, and sort the list by that sentence.

A technical debt list with no owner and no rough time estimate becomes a graveyard nobody ever revisits. Assign each item a name and a rough sense of the engineering effort to address it, and review the whole list on a fixed cadence instead of letting it grow indefinitely without anyone actually triaging it against current priorities.

• Put the review on the calendar in advance, not scheduled for whenever there happens to be time, since that's how it quietly never happens again after the first one.
• Rebuild the dependency map from real data each time rather than trusting last quarter's version, since services and their connections change faster than anyone remembers to update a document manually.
• Retire technical debt items that got fixed, and add any genuinely new ones, so the list stays a working tool people trust instead of an artifact everyone silently ignores.

Include the engineers who actually own the highest-risk services, not only engineering leadership. A review built entirely by managers, without the people closest to the code, tends to miss exactly the risk that everyone doing the day-to-day work already knows about but has simply never been asked to write down in one place.

A review that surfaces three single points of failure and adds a page of technical debt items accomplishes nothing on its own if none of it ever reaches a roadmap. Bring the highest-risk finding from each review into the same planning process as any other engineering work, with the same expectation that it gets prioritized against feature work rather than permanently deferred because it doesn't have a customer-facing deadline attached to it.

Track whether findings from the previous review actually got addressed as part of running the next one. A pattern of the same single point of failure appearing on the list quarter after quarter with no progress is itself a useful signal, worth raising as its own conversation rather than quietly re-documenting the same risk indefinitely.