2 Understanding the problem

Engineers are naturally drawn to solutions, but the chapter argues that strong architectural decisions begin by understanding the problem first. It uses search as a recurring example to show how teams often jump too quickly to familiar answers such as a CRM, a message queue, or full-text search, when the real need may be simpler and better served another way. The key habit is to stay with the underlying job, listen directly to users when possible, and treat engineering as an active participant in shaping requirements rather than a downstream recipient of them.

From there, the chapter explains how to identify the requirements that truly shape architecture. These architecturally significant requirements are the ones that would force a redesign if missed, because they introduce major complexity, new infrastructure, or whole new components. Non-functional needs are handled through service tiers for availability, durability, latency, load, and volatility, which help teams discuss trade-offs in practical terms instead of abstract numbers. The same capability can sit in very different tiers depending on context, and that context should drive whether the team chooses simplicity, scaling, redundancy, caching, or decoupling.

The chapter also treats compliance as a distinct kind of constraint. Legal requirements are usually binary and should be separated from the specific controls used to satisfy them, while security should be framed through threat modelling and risk-based controls. The practical message is to involve legal, security, product, and engineering early, document the link between requirements and controls, and avoid overengineering when a lighter control is sufficient. When the problem is clear, the architecturally important requirements are identified, and the non-functional and compliance constraints are understood, the team is ready to have a solution discussion with fewer surprises and better trade-offs.

Architecture changes required to add full-text search requirement.

Response time boundaries.

Spider diagrams placing search systems in different service tiers.

Threats lead to identification of security requirements and controls.

Steps to cover before moving to the solution conversation.

• The quality of the decision is bounded by the quality of our understanding of the problem. Requirements gathering is the work of building that understanding, an essential part of the decision lifecycle
• Engineers who rush to solutions risk to solve the wrong problem, or the right problem in the wrong way, because they missed a constraint, an assumption, or an expectation.
• Jobs-to-Be-Done framing or a simple alternative set of questions is a useful lens to ensure staying with the problem long enough to not shortcut to the solutions space.
• Direct exposure to user research changes the shape of architectural decisions. People who have seen the workflow tend to optimize for the problem as it actually exists.
• Architecturally significant requirements (ASRs) are the requirements where, if we miss them, the architecture itself needs to change. The "What would break this" test asks which additional functional requirement would force us to abandon the current design, and it is how we separate ASRs from requirements that merely shape implementation.
• ASRs deserve architectural-level attention. Most other requirements can be settled at implementation time, where the cost of changing course is much lower.
• Non-functional requirements are rarely clearly defined. Translating expectations into tiered options gives stakeholders a shared vocabulary and a set of commitments we can design against – Basic through Critical for availability, Minimal through Very High for durability, Instant through Background for latency.
• Availability and durability are best discussed together, because they are achieved through the same topology decisions.
• Latency tiers track human perception thresholds that operate whether we acknowledge them or not.
• Throughput is context-dependent, but the tier idea still applies – different components of the same system live at different scales.
• Volatility is a property of how often the implementation is expected to change. Different parts of a system belong at different tempos – Foundational, Seasonal, Campaign, or Ephemeral.
• Compliance is different in shape from the other non-functional dimensions. Legal obligations are mostly binary, security is risk-and-control rather than tiered.
• Both are best handled by engaging the relevant experts while architectural options are still open, and by keeping requirements separate from controls.
• A problem description is ready for solution discussion when the job is identified independently of the system, the ASRs have been found jointly, each non-functional dimension has a tier, the compliance constraints are on the table.

FAQ