Choosing Complexity by Requirement, Not Capability

Modern platforms make sophisticated architecture surprisingly accessible. It is easy to add queues, multiple services, real-time events, distributed caches, and several deployment environments before the business problem has demonstrated a need for them.

The availability of a capability is not evidence that a system requires it.

I prefer to evaluate complexity as a cost that must be justified. Every architectural component creates more than an implementation task. It adds another place to monitor, secure, explain, test, deploy, and recover when something fails.

Begin with concrete pressure

A useful decision starts with the pressure the system is actually experiencing or can reasonably expect. Examples include:

• a synchronous operation is too slow for a user request;
• one workload needs to scale independently;
• a failure must not block the main transaction;
• sensitive responsibilities require stronger isolation;
• a team cannot deploy safely because components are too tightly coupled;
• measured traffic or data volume has exceeded the current design.

These are requirements or constraints. “This technology is more scalable” is not yet a requirement.

Compare the complete cost

Suppose a background queue could improve a workflow. The comparison is not simply queue versus no queue. It includes retry behavior, duplicate processing, failure visibility, ordering, monitoring, operational ownership, and what happens when the queue is unavailable.

The same principle applies to service boundaries. A separate service may create useful isolation, but it also introduces network failure, version coordination, distributed tracing, access control between components, and additional deployment responsibility.

Sometimes those costs are justified. The point is to make them visible before deciding.

Team capability is an architectural constraint

A design that looks clean on a diagram can become unreliable if the team cannot operate it confidently. Architecture must account for who will build, maintain, and diagnose the system—not only its theoretical properties.

This does not mean a team should never adopt unfamiliar tools. It means the learning and operational burden belongs in the decision. A simpler design that the team can understand deeply may be safer than a more advanced design that depends on shallow familiarity.

Preserve the option to evolve

Choosing simplicity should not mean ignoring future change. Clear data ownership, explicit module boundaries, stable interfaces, and reliable tests can make a system easier to separate later without paying the cost of distribution immediately.

The goal is not to predict every future requirement. It is to avoid choices that make reasonable future changes unnecessarily expensive.

My current decision test

Before adding significant complexity, I ask:

1. What verified requirement or risk does this address?
2. What is the simplest alternative?
3. What new failure modes and operational duties will it create?
4. Can the current team support it responsibly?
5. What evidence would tell us the decision was useful?

Good architecture is not the architecture with the most capabilities. It is the simplest architecture that responsibly meets the business requirements, scale, risks, budget, and capabilities of the team building it.