What Customers Actually Ask in Architecture Reviews

Architecture reviews are never really about the diagram.

The diagram matters. The services matter. The network paths matter. The data flow matters. The security boundaries matter.

But the real conversation usually starts after the diagram is on the screen. That is when customers stop asking what the system is supposed to do and start asking what happens when reality shows up.

What happens when it fails? What happens when traffic doubles? What happens when the team that built it leaves? What happens when the bill shows up? What happens when security asks who approved this? What happens when the business wants to expand into another region?

That is what customers actually ask in architecture reviews. Not always directly. But that is what they are trying to understand.

Customers are not buying the clean path#

Most architecture diagrams show the happy path. User hits the application. Application calls the API. API talks to the database. Events go to a queue. Logs go to monitoring. Everything is clean.

But customers know systems do not run on the happy path. They run in production.

Production is retries, latency, partial failures, expired certificates, noisy neighbors, quota limits, bad deploys, schema changes, DNS issues, permission drift, and weekend incidents.

So when a customer looks at an architecture, they are not just asking: "Does this work?" They are asking: "Can we live with this when it does not?"

That is the real review.

The first question is usually ownership#

One of the most important questions is also the least technical: Who owns this?

Who owns the application? Who owns the database? Who owns the network? Who owns the identity model? Who owns the disaster recovery plan? Who owns the runbook? Who gets paged at 2 a.m.?

A beautiful architecture with unclear ownership is not production-ready. Customers know this. They may ask it politely, but the concern is direct: "If this breaks, who is responsible for fixing it?"

That question matters more than most teams want to admit.

The second question is failure#

Customers always want to know what happens when something fails. Not because they are negative. Because they have been through enough outages to know every system eventually fails somewhere.

What happens if a zone goes down? What happens if the database fails over? What happens if a region is unavailable? What happens if the queue backs up? What happens if the identity provider has an issue? What happens if an API dependency is slow? What happens if the deployment fails halfway? What happens if replication lags? What happens if the restore does not work?

Architecture reviews are where confidence meets failure modes. A weak architecture explains how things work. A strong architecture explains how things fail and recover.

Customers ask about recovery, not just availability#

A lot of teams talk about high availability as if it solves everything. Customers know better. Availability is only part of the story.

They want to know: How much data can we lose? How long can we be down? How do we know failover worked? How often do we test recovery? Who declares a disaster? Who has permission to execute the recovery plan? How do we bring the system back without making things worse?

That is why RPO and RTO matter. Not as checkbox terms. As business commitments.

If the business says the system can only be down for five minutes, the architecture has to prove it. Not with hope. With design, process, and testing.

Customers ask where the data lives#

Data location is one of the first things serious customers care about.

Where is the data stored? Which region? Which replica? Which backup? Which log store? Which analytics system? Which AI pipeline? Which team can access it? How long is it retained? Is it encrypted? Can it leave the country? Can support engineers see it? Can developers see production data? Can the model see it?

That last question is becoming more important. AI has made data boundaries visible again.

Customers want innovation, but they also want control. They need to know where sensitive data goes, how it is protected, and whether the architecture respects their compliance requirements.

A good architecture review makes data movement obvious. A bad one hides it behind arrows.

Customers ask about identity#

Identity is the architecture now.

Customers want to know: Who can access what? How are permissions assigned? Are we using managed identities? Are secrets stored properly? Are keys rotated? Can access be audited? Are admins separated from operators? Can the application call the database without passwords? What happens when an employee leaves? Can we prove least privilege?

This is especially true when systems start integrating AI agents, automation, APIs, and cross-service workflows.

The question is no longer just: "Can this service call that service?" The question is: "Should it be allowed to?"

Customers ask about scale#

Scale questions are rarely abstract. Customers usually have a business event in mind.

A product launch. A seasonal peak. A migration wave. A new region. A new customer onboarded. A regulatory deadline. A batch process that keeps growing. A new AI feature that increases read pressure.

They ask: What happens if traffic doubles? What happens if the database grows from 2 TB to 20 TB? What happens if we need ten read replicas? What happens if our ingestion rate spikes? What happens if vector search becomes part of the critical path? What happens if we need to onboard 500 stores instead of 50?

Architecture reviews expose whether the design scales cleanly or whether every growth step requires a new exception.

Customers ask about latency#

Latency is one of the most practical customer questions.

Where is the user? Where is the app? Where is the database? Where are the integrations? Where is the model? Where is the cache? How many network hops are in the critical path? How does this behave under load?

Latency is not just a performance detail. It is product experience. A slow database call becomes a slow API. A slow API becomes a slow app. A slow app becomes an unhappy customer.

In architecture reviews, customers want to know whether latency has been designed for or discovered by accident.

Customers ask about cost#

Cost is always in the room. Even when nobody starts there.

The architecture may be technically correct, but customers still want to know: What are we paying for? What scales with usage? What stays on all the time? Are we over-provisioned? What happens to cost when replicas are added? What happens when logs grow? What happens when backups accumulate? What happens when AI calls increase? What happens when storage grows faster than compute?

The best architecture conversations do not treat cost as a finance problem. Cost is an architecture signal. A design that cannot explain its cost model is not complete.

Customers ask about operations#

The question is not only: "Can we deploy this?" The better question is: "Can we operate this?"

Customers ask: How do we monitor it? What alerts matter? What does healthy look like? What does degraded look like? Where are the logs? Where are the traces? How do we debug a failed request? How do we patch it? How do we roll back? How do we test changes safely? Who approves production deployments?

Production architecture is not just infrastructure. It is operations. A system that cannot be observed cannot be trusted.

Customers ask about migration#

A lot of architecture reviews are really migration reviews. The customer is not starting from zero. They already have systems, data, teams, processes, contracts, deadlines, and politics.

So they ask: How do we move without breaking the business? Can we run old and new in parallel? How do we validate data? How do we cut over? How do we roll back? How much downtime is required? Which applications must change? Which stored procedures must be rewritten? Which reports depend on this database? Who signs off?

Migration is where architecture meets reality. The best design in the world still has to survive the path from where the customer is today.

Customers ask about what is not shown#

The most important parts of the architecture are often missing from the first diagram.

Backups. Secrets. DNS. Private endpoints. Firewalls. Monitoring. Runbooks. Approvals. Break-glass access. CI/CD. Data retention. Support model. Incident response. Cost controls. Testing strategy.

Customers notice. They may not say it directly, but they are looking for the gaps. A good architecture review brings those things into the conversation before the customer has to ask.

The best architects answer the question behind the question#

When a customer asks, "Is this highly available?" they may really be asking: "Will I get blamed if this goes down?"

When they ask, "Can this scale?" they may really be asking: "Will this survive the business plan?"

When they ask, "Is this secure?" they may really be asking: "Can I defend this to risk and compliance?"

When they ask, "How much does it cost?" they may really be asking: "Will this surprise me six months from now?"

Architecture reviews are not exams. They are trust-building exercises. The job is not to sound smart. The job is to reduce uncertainty.

Customers do not actually care how pretty the architecture diagram is. They care whether the design can survive production.

They care who owns it. They care how it fails. They care how it recovers. They care where the data lives. They care who can access it. They care how it scales. They care how much it costs. They care how it is operated. They care how they migrate to it without breaking the business.

That is what customers actually ask in architecture reviews.

The best architects do not hide behind the diagram. They use the diagram to have the real conversation.