System Architecture Isn't Tech Selection: The Critical Questions for Production Readiness

AI-assisted coding accelerates functional implementation, but it does not replace the architectural judgment that engineers traditionally gain through debugging, production incidents, and system evolution. An InfoQ article referencing a QCon London talk warns that skipping the execution phase may leave experience gaps, making deliberate architectural training more important than ever.

Architecture Is Not Technology Selection

Many teams start architecture discussions by debating microservices, message queues, databases, or Kubernetes. These decisions matter, but they must not be the starting point. Architecture must first answer: what business does the system serve, who are the users, what is the impact of failure, which quality attributes are required, and can the team sustain long-term ownership.

Experienced architects work from business scenarios and constraints — deployment environment, existing infrastructure, data scale, integration limits, delivery cadence, operational capacity, and budget — to choose appropriate technologies. No single technology solves every problem; each brings benefits, costs, and applicability conditions. Architecture is a continuous trade-off among business value, risk, quality attributes, reality, and long-term responsibility, not a search for the most advanced stack.

Quality attributes, system boundaries, collaboration patterns, and technical feasibility influence each other iteratively. Without these constraints, teams default to familiar or trendy technologies, producing diagrams full of gateways, caches, and queues that reveal nothing about business boundaries, data consistency, critical paths, or failure recovery ownership.

Translate Business Goals into Quality Attributes

Business requirements describe what the system must do; architecture must ask to what level. A refund processing feature may be stated in a few sentences, but duplicate requests, channel timeouts, consistency, permissions, audit, alerting, and recovery directly shape interfaces, state models, data boundaries, collaboration, and deployment — they are not afterthoughts.

The article organizes these concerns into quality attribute scenarios:

Correctness : prevent duplicate refunds and amount errors → idempotency rules, state machines, reconciliation, compensation.

Availability : accept requests when external channels fail → sync vs async, queues, degradation strategies.

Performance & Capacity : peak refund volume and latency targets → task model, concurrency control, capacity planning.

Security : who can initiate, approve, query refunds → identity, permissions, data isolation.

Recoverability : continue after timeouts, restarts, partial success → checkpoints, retries, compensation, manual intervention.

Observability : detect backlogs, failures, data discrepancies → metrics, logs, traces, alerts.

Evolvability : contain impact of changing payment channels and refund rules → business boundaries, adapters, interface contracts.

Specific availability, latency, and recovery targets must be grounded in business risk, real scale, and cost; unjustified high targets only add unnecessary complexity. As Production-Ready Microservices notes, availability is a goal, not a design method — a number alone does not tell a team how to design, deploy, and operate a system. Goals must become executable, verifiable, owned architectural constraints.

System Topology and Collaboration Patterns Are Separate Decisions

After quality attributes are clarified, system boundaries, collaboration patterns, and technical feasibility must be compared together and re-evaluated as information grows. Using the refund example, two topological candidates are compared:

Modular Monolith : suitable for small teams, limited scope, tight refund-order coupling. Benefits: simple deployment, local transactions, low debugging cost. Costs: limited independent scaling and team autonomy.

Independent Refund Service : suitable for complex rules, dedicated team, different release and capacity needs. Benefits: clear responsibility and data boundaries, independent evolution. Costs: remote calls, distributed state, operational overhead.

Neither choice is justified merely because refunds look like an independent function or because the team is currently small. Service boundaries must be decided by business complexity, data ownership, team responsibility, and runtime requirements.

Collaboration patterns are then evaluated independently:

Synchronous calls: for immediate response on stable short paths, but dependency failures directly affect the request.

Asynchronous tasks: for accept-now-complete-later, peak shaving, or failure recovery, requiring state, idempotency, backlog, and failure handling.

Event-driven: for multiple capabilities reacting to the same change, requiring contract, ordering, duplicate, and eventual consistency management.

A modular monolith can use async tasks; microservices do not mandate event-driven everything. Topology and collaboration are related but distinct decisions. If the team is small and rules are volatile, a well-bounded modular monolith with adapter-wrapped payment channels and internal recoverable async tasks may be the right starting point, deferring service extraction until scale, team ownership, or independent release needs change.

Six-Perspective Architecture Check

A single component diagram is insufficient to verify architectural completeness. The author uses six perspectives to spot gaps:

Business: core capabilities, flows, rules, risks.

Application: module/service division, call and state flow.

Data: data responsibility, storage, sharing, consistency, recovery.

Technology: mechanisms and dependency directions supporting quality goals.

Deployment: release, scaling, isolation, rollback.

Organization: who designs, develops, on-calls, recovers, and accepts risk.

This framework complements but does not replace methods like 4+1 or C4; it does not require six separate documents, but reminds teams not to stop at a technology component diagram. For example, a refund service may appear independent in the application view yet share a database with the order service (data boundary not independent), or be independently deployable but lack a team owning alerts and recovery (deployment boundary without runtime responsibility), or have business logic directly coupled to a payment SDK (external changes penetrate core logic). Each drawn boundary must be checked for real support in data, dependencies, deployment, and ownership.

Observability, Fault Tolerance, and Security Must Enter at Design Time

These concerns are often deferred to late development: add logs, retries, permissions, audit before launch. The problem is they change system structure. Audit requires stable business identifiers at every state change and manual operation. Recovery demands distinguishing failure from unknown result, designing checkpoints and reconciliation. Preventing duplicate refunds requires idempotency constraints in interfaces and state models. Detecting backlogs early requires metrics and status from task creation.

These requirements must land in explicit responsibilities: architecture/governance roles define state models, failure classifications, trust boundaries, audit requirements; platform teams provide default capabilities for release, observability, secrets, alerts, and automated gates; service teams maintain rules and SLOs, handle alerts, execute recovery; risk acceptors decide on residual risk. If responsibility stays only in documents, production readiness will not happen.

Architectural Claims Must Withstand Evidence-Based Validation

Architecture is not a set of plausible principles but a set of verifiable hypotheses. For the refund system, the article maps judgments to verification targets and evidence sources:

Duplicate requests cause no duplicate refunds → same business key yields one valid refund → idempotency tests, state records, channel reconciliation.

Channel anomalies do not lose tasks → tasks continue or escalate after timeout/restart → fault injection tests, recovery drills.

System handles target throughput → latency, backlog, resource usage meet goals under peak → load test reports, capacity baselines.

Issues are traceable → one refund correlates request, task, channel, state changes → logs, metrics, traces, audit records.

Service is sustainably owned → alerts handled, runbooks executable → on-call records, runbooks, drill results.

Without such evidence, the architecture only states goals, not proven capabilities. AI can generate diagrams, candidates, test code, and run checks, but it cannot accept business risk on behalf of the team. An agent's self-reported "design reasonable" or "tests passed" cannot replace independent toolchain results or real production evidence.

Architecture Is Not a One-Time Answer

Before development, a baseline of key architectural decisions must be executable, but not every detail needs to be finalized. The author runs technical spikes — prototypes, tests, critical path experiments — to confirm whether candidates satisfy business scenarios and quality requirements. Spikes are not to prove a pre-chosen direction; if evidence contradicts assumptions, the direction changes.

During development, architecture continues: emerging boundary, dependency, performance, and feasibility issues must be analyzed and resolved, sometimes correcting decisions and updating the baseline. A healthier process: fix key goals, boundaries, irreversible decisions, and validation methods first, then let implementation and runtime feedback continuously refine the design.

Low-cost, reversible technical details can be deferred; decisions that alter data boundaries, team responsibilities, external contracts, or recovery paths must be made early. Clean Architecture separates high-level business policy from databases and frameworks to reduce change impact and preserve options — not to avoid technical decisions, but to prevent specific technologies from controlling the system before problems are understood.

After production, architecture must keep evolving. Real traffic, failures, user feedback, and collaboration friction expose assumption drift. Architecture documents should record these changes, not just the initial ideal design.

This approach has limits. Low-risk, short-lived internal tools do not need six documents or complex microservice platforms, but they still need clear business boundaries, failure impact, data ownership, runtime ownership, and basic validation. Architectural investment should match business risk, system lifespan, and change cost.

AI Era Demands Explicit Architectural Reasoning

Historically, engineers learned which boundaries spiral out of control, which technologies leave long-term debt, and which designs the team cannot maintain — through failures, rework, and evolution. AI speeds up implementation but creates a new problem: engineers get answers faster without experiencing the process that forms those answers.

Therefore, this series does not merely prescribe "what to use" but preserves the full reasoning path from business context, constraints, risks, and candidate options to architectural decisions, verification evidence, and runtime corrections. For less experienced engineers, the training need is not memorizing more architecture terminology, but knowing what to keep asking when facing a concrete problem, how to compare alternatives, and on what grounds to accept a conclusion.

Summary

System architecture is not technology selection, nor drawing components on a diagram. It begins with business goals and risks, translates needs into quality attributes, establishes boundaries across business, data, system, and team, selects technologies and operational mechanisms the team can sustain, and continuously validates those decisions with independent evidence.

Architecture is not deciding upfront what technology the system will use,
but continuously deciding: which constraints must be satisfied, which costs can be accepted, who owns the outcome.

The next article will address the most misunderstood aspect of overall architecture: why service decomposition is not just drawing boxes, and how business boundaries, team topology, and runtime responsibility should align.