Skip to content
Jakarta, Indonesia, UTC+7 Currently CTO at Sxored
EN ID
ALM ALM Abdul Latif Munjiat
ALM ALM
EN ID
Back to blog
EN Platform 2026-07-11 · 9 min read

What I actually check before approving an architecture

Six questions, in order. Most designs fail on the third one, and it is never the interesting part of the diagram.

Abdul Latif Munjiat
Abdul Latif Munjiat CTO at Sxored, Jakarta

A design review is not a place to admire a diagram. I have sat in reviews where the boxes and arrows were immaculate and the system still fell over in its first month, because the failure everyone missed was a vendor that answers in nine seconds instead of two hundred milliseconds.

So I stopped reviewing designs freeform. I ask the same six questions, in the same order, and I do not move on until each one has a concrete answer. The order matters. It puts the boring questions before the interesting ones, which is exactly where the risk lives.

The six questions

01

What breaks first, and how do we find out?

Name the component that fails under load before anything else does. If nobody can name it, the design has not been thought through, it has been drawn.

02

Where does data live, and who is allowed to read it?

In regulated finance this is a design-time decision, not an audit-time one. Residency, retention and deletion belong in the diagram, with owners.

03

What happens when the slow dependency is slow?

Fails here

Not down. Slow. Timeouts, retries, queue depth, and what the user sees while it all happens. This is the question most designs cannot answer.

04

What does this cost at ten times the volume?

A rough number is enough. I am not looking for accuracy, I am looking for whether anyone has thought about the bill before finance does.

05

Who gets paged, and what do they do at 3am?

If the answer is a person rather than a runbook, we designed heroics into the system. That is a defect, not a staffing plan.

06

What is the cheapest thing that would also work?

Asked last, on purpose. By this point the team has defended the design, so the honest comparison is finally possible.

Why question three is the one

Teams plan for outages. Outages are dramatic, they have a status page, and everyone knows what to do. Degradation is quieter. A third party that normally answers in two hundred milliseconds starts taking six seconds, nothing throws an error, and every worker in the pool is busy waiting. The queue grows, the retries pile on top of the original load, and by the time an alert fires the system is doing nothing except making the problem worse.

In document processing this is routine. A bank statement takes as long as it takes, and the upstream vendor has a bad afternoon roughly once a quarter. So the answer has to exist before the incident: a timeout budget per hop, a circuit breaker that trips on latency and not only on errors, a bounded queue that sheds instead of swallowing, and a user-visible state that says the result is coming later rather than pretending it is coming now.

Resilience is a design-time decision. Everything you add after the first incident is a patch, and patches are how systems get complicated.
What I say in most reviews

When the answer is missing

I do not reject the design. I write the unanswered question at the top of the document and send it back with a date. Nine times out of ten the second version is smaller than the first, because answering question three honestly usually removes a component rather than adding one.

The last thing I want is a review where I am the smartest person in the room. Six fixed questions mean the team can run the check without me, which is the only version of this that scales.

Filed under Platform Architecture Leadership