Architectural drivers: what guides architecture decisions

One of the most common ways to get architecture wrong is to jump to the solution too early:

“We have to use microservices.”

“We need Kafka.”

“This should run on Kubernetes.”

These statements may well turn out to be right, but they still don’t explain why. An architecture should start from a different question:

What does the system need to do, under what conditions, and within what constraints?

Architectural drivers are the requirements and constraints with enough impact to shape architecture decisions.

flowchart LR
  A["Requirements"] --> C["Drivers"]
  B["Constraints"] --> C
  C --> D["Decisions"]

Not every requirement carries the same architectural weight. One more screen probably won’t change the structure of the system. A requirement like 99.99% availability or 10,000 requests per second can.

Requirements

Requirements describe what the system has to offer and the properties it has to meet. For architecture it helps to split them into two broad groups:

• Functional requirements
• Quality attributes

Functional requirements

Functional requirements describe what the system has to do. In a Payments system, for example:

• Create Payment
• Authorize Payment
• Capture Payment
• Refund Payment
• Process Provider Webhook

A requirement might be:

The system must allow a payment to be authorized through any of the supported payment providers.

This requirement defines behavior, but it still doesn’t tell us:

• how long it should take;
• how much traffic it has to handle;
• what happens if the provider doesn’t respond;
• how we avoid duplicate charges;
• where the information is persisted.

That belongs to other dimensions.

Functional requirement vs. implementation

A frequent mistake is turning a requirement into a solution:

“Payments must use Kafka to process authorizations.”

That’s no longer a functional requirement. It’s a technical decision. The difference matters:

flowchart LR
  R["Requirement:<br/>'A payment must be authorizable'"] -.is not the same as.-> D["Decision:<br/>'Authorization will be processed through X'"]

The architecture should follow from the problem, not the other way around.

Quality attributes (non-functional requirements)

Quality attributes describe properties of the system: how it has to behave while carrying out its functions. Some of the most common ones:

• Performance
• Availability
• Reliability
• Scalability
• Security
• Consistency
• Durability
• Maintainability
• Operability
• Cost

There’s no universal, closed list; the vocabulary varies between frameworks and organizations. What matters is turning abstract attributes into observable targets.

Performance

Performance is usually split, among other dimensions, into latency and throughput (processing capacity):

Throughput
10,000 requests / second

These are different concepts: a system can handle 20,000 requests per second and still show high latencies. It can also have excellent latency for a single request and little capacity for concurrency.

Latency and percentiles

In real systems it’s usually not enough to say:

“The response takes 100 ms on average.”

Percentiles are the common tool:

For example, a p99 of 350 ms means 99% of requests responded in 350 ms or less, while the remaining 1% took longer.

This exposes part of the distribution that the average can hide, and it’s especially useful for spotting latency problems in the slowest requests.

Availability

Availability expresses what proportion of the time the system is up. Some approximate annual downtime figures:

The jump from 99.9% to 99.99% looks small, but it can take considerably more infrastructure and recovery capability. That’s why availability has to be a business target, not just a number picked out of habit.

Reliability

Reliability and availability aren’t the same thing. Take this flow:

sequenceDiagram
  participant C as Client
  participant S as Payments Service
  C->>S: POST /payments
  S-->>C: HTTP 200
  Note over S: Payment charged twice

The system was available and responded correctly as far as HTTP is concerned. It still produced a wrong result. Reliability is about the system carrying out its function correctly and consistently.

Scalability

Scalability describes how a system responds as load grows. You can scale vertically (a bigger machine) or horizontally (more instances), but the answer isn’t always “add machines”. The bottleneck could be the database, the network, CPU, memory, locks, hot partitions, an external provider, or the consumers of a queue.

That’s why a requirement like:

“The system must scale”

is too vague. A more useful one would be:

“The system must handle 10,000 RPS at peak while keeping p95 below 300 ms.”

That one can actually guide architecture decisions.

Security

Security covers several aspects of the system, among them:

• Authentication
• Authorization
• Confidentiality
• Integrity
• Encryption
• Secrets management
• Principle of least privilege
• Auditability

In a Payments system, for example, this means answering questions like:

• Who can issue a refund?
• What data can each role see?
• Where are credentials stored?
• How are secrets protected?
• How are sensitive operations audited?

Consistency

Consistency describes when different parts of the system have to see the same data. For example:

This can be completely unacceptable, acceptable for a few seconds, or irrelevant for certain reads. It depends on the domain. The right architectural question is:

Which operations require strong consistency, and where can we accept eventual consistency?

Durability

Durability describes the ability to keep data once it has been committed. It matters especially for:

• Payments
• Orders
• Transactions
• audit logs
• financial records

It isn’t enough for an endpoint to return 200 OK if the data can disappear afterwards.

Constraints

Requirements describe what we need. Constraints limit the solutions we can choose:

• Technical constraints
• Business constraints

Technical constraints

Examples:

• Must run on AWS
• Must use PostgreSQL
• Must integrate with a legacy PHP system
• Must use the existing Kafka infrastructure
• Must be compatible with Java 21

A technical constraint can come from:

• existing infrastructure;
• contracts;
• internal standards;
• the team’s expertise;
• earlier migrations;
• compliance.

Business constraints

Examples:

• Budget
• Deadline
• Team size
• Existing contracts
• Regulations
• Market requirements
• Operational capacity

Picture this:

With a team of 4, 4 months, and a limited budget, a multi-region architecture usually adds more complexity than a 99.9% target calls for.

From requirements to architectural drivers

Take a Payments system:

Functional

• Authorize payment
• Capture payment
• Refund payment

Quality attributes

• p95 < 300 ms
• 99.99% availability
• 10k RPS at peak
• No duplicate charges

Constraints

• AWS
• PostgreSQL
• Existing providers
• Small team

The resulting drivers might be:

flowchart TD
  AD["Architectural drivers"]
  AD --> H["High availability"]
  AD --> L["Low latency"]
  AD --> T["High throughput"]
  AD --> I["Idempotent processing"]
  AD --> S["Secure operations"]
  AD --> O["Operational simplicity"]

When this analysis is especially useful

When several architectures look reasonable. If an application has 50 users, 10 RPS, and a 99.5% availability target, there’s probably no strong reason to distribute the system. If instead it has 500,000 users, 50k RPS, a 99.99% availability target, a need for independent scaling, and several teams working in parallel, the discussion changes completely.

When not to overdo it

Not every project needs a 50-page requirements document. The key is identifying the requirements that can actually change the architecture.

Common tools

Requirements and constraints can be captured in Jira, Linear, Confluence, Notion, GitHub Issues, or architecture documents. The tool is secondary: what matters is that the drivers are explicit.

References

• AWS Well-Architected Framework — principles for evaluating architectures across areas such as operational excellence, security, reliability, performance efficiency, and cost optimization.
• Microsoft Azure Architecture Center — material on architectural styles and how to evaluate them by their benefits, challenges, and context.