Architecture Primitives

An architect who knows many patterns is less useful than one who knows when each pattern is wrong.

For each primitive: what it is, when to use it, and when it will hurt you.

Boundaries and Ownership

What it is. Drawing lines between components so each has a clear owner, clear interface, and can evolve independently.

When it's right. When different teams own different parts. When components have different scaling, deployment, or reliability requirements. When you need to limit blast radius.

When it's wrong. When the "boundary" creates more cross-boundary coordination than it prevents. When data that changes together is split across boundaries. When the team is small enough that communication overhead exceeds boundary value.

Contracts and Interfaces

What it is. Explicit agreements between components about what they provide and expect — API schemas, message formats, SLAs, error codes.

When it's right. At every boundary. Between any components that evolve independently. When multiple consumers depend on the same provider.

When it's wrong. Premature contracts between components that are still being designed together. Overly rigid contracts that prevent necessary evolution. Contracts without versioning strategy.

Source of Truth

What it is. For every piece of state, exactly one system is authoritative. All others are caches, replicas, or derived views.

When it's right. Always. Every system should be able to answer "where is the source of truth for X?"

When it's wrong. Never wrong as a concept — but wrong when applied as "one database for everything." Different data has different truth owners.

Synchronous vs. Asynchronous Communication

What it is. Sync: caller waits for response. Async: caller sends message and continues.

When sync is right. When the caller genuinely cannot proceed without the response. User-facing request/response flows. Reads that must be consistent.

When sync is wrong. When the caller doesn't need the result to continue. When the called service is slow or unreliable. When you're creating temporal coupling between services that don't need it.

When async is right. When work can be deferred. When you need to absorb load spikes. When producer and consumer should be independently deployable and scalable.

When async is wrong. When you need an immediate, consistent response. When the added complexity of message delivery, ordering, and failure handling exceeds the benefit.

State Machines

What it is. Modeling entities as having explicit states with defined transitions. An order is "placed → confirmed → shipped → delivered," not a bag of boolean flags.

When it's right. When an entity has a lifecycle with distinct phases. When invalid state transitions are a real failure mode. When you need to audit or replay state changes.

When it's wrong. When the entity's behavior doesn't meaningfully vary by state. When the state space is too large to enumerate. When you're adding a state machine to something that is really just a CRUD record.

Queues and Buffering

What it is. Decoupling producers from consumers with an intermediate buffer. Smooths out rate differences and absorbs spikes.

When it's right. When producer rate exceeds consumer rate temporarily. When consumer failures shouldn't block producers. When you need to prioritize or reorder work.

When it's wrong. When the queue grows unboundedly (you've moved the problem, not solved it). When end-to-end latency matters and the queue adds unacceptable delay. When queue failure becomes a single point of failure worse than direct coupling.

Caches

What it is. Storing computed or fetched results closer to the consumer to avoid repeated expensive operations.

When it's right. When reads vastly outnumber writes. When the source is slow and staleness is acceptable. When the working set fits in memory.

…