The Architecture Decisions That Matter More Than Your Tech Stack

Teams spend weeks choosing between React and Vue, or Go and Kotlin, and then lose years to decisions they made in an afternoon: one shared database for everything, services that must be deployed together, a “utils” package that every module imports. The stack sets your starting point. Boundaries, coupling, data ownership and deployability decide how fast you can change later. This post explains those decisions, how to spot the expensive ones, and how to record them.

Why It Matters

The research behind Accelerate (the DORA program) found that teams with loosely coupled architectures, where teams can test and deploy without coordinating with others, deliver more often and with fewer failures, regardless of whether they ran on mainframes or the cloud. In other words, what predicted performance was the shape of the system, not the technology in it.

The Vocabulary in Two Minutes

If you are newer to architecture, these are the words the rest of this post uses. Software architecture is simply the set of decisions that are hard to change later: like the walls of a building, as opposed to the furniture.

Good architecture means high cohesion inside each module and low coupling between them, so most changes stay inside one module and its team.

The Decisions That Compound

1. Where You Draw Boundaries

A boundary is a line that code and data don’t cross except through a deliberate interface. The classic guidance, from David Parnas in 1972, still holds: split a system around decisions likely to change, so each change stays inside one module. Splitting by technical layer (controllers, services, repositories) spreads every feature across all of them; splitting by business capability (orders, payments, identity) keeps most changes local.

Layers are still useful inside a module. The point is which line comes first: put the business capability on the outside, so the folder structure matches the way the product changes.

2. How Tightly Parts Are Coupled

Coupling is how much one part must know about another to work. Some coupling is unavoidable; the goal is to keep it weak and explicit:

Synchronous call chains deserve a closer look, because they couple services in time: each one is only up when everything it calls is up.

Queues aren’t free: the order is now “placed” before inventory has confirmed it, so the system needs a way to handle “sorry, that item just sold out”. That trade-off (availability now, consistency a little later) is an architecture decision, and it should be made on purpose.

3. Who Owns Which Data

Shared databases are the most common hidden coupling. When two services write the same table, neither can change its schema without the other, and nobody owns the data’s correctness. Give every important piece of data one owner that is allowed to write it, and let everyone else read through that owner’s API or a published copy.

4. Whether Parts Can Be Deployed Independently

If changing the checkout page requires a coordinated release with three other teams, you have a distributed monolith: the costs of distribution (network failures, versioning) without the benefit (independent change). Independent deployability is the test that tells you whether your boundaries are real.

Monolith, Modular Monolith or Microservices?

These four decisions add up to an architecture style. The common options, from simplest to most distributed:

A good path for most products: start as a modular monolith, enforce its boundaries, and extract a service only when a specific module needs its own deploys, scaling or team.

Neither story means “microservices are bad”. Both mean the boundaries should follow the needs of the work (its change rate, load and team structure), not what is fashionable.

A Worked Example: An Online Shop Growing Up

• Year 1: one app and one database, but the code is already split into orders, payments and catalog, each with its own folder and API.
• Year 2: a lint rule blocks imports into other modules’ internals, and each module owns its tables.
• Year 3: a separate payments team needs weekly compliance releases, so payments is extracted as a service behind the same API.
• Later: another module is extracted only when a team, scaling or compliance need appears.

What made year 3 cheap were the decisions in years 1 and 2. Because payments already had one owner, its own tables and a clear API, extracting it was a deployment change rather than a rewrite. Boundaries drawn early are what make later options cheap, whatever the stack.

One-Way and Two-Way Doors

Not every decision deserves a meeting. A useful test, popularized by Amazon, separates two-way doors (easy to reverse: decide fast) from one-way doors (expensive to reverse: decide slowly and write it down):

The trick is to turn one-way doors into two-way doors where you can: hide a vendor behind an interface you own, version public contracts, and keep data access behind one owner so storage can change later.

Write Decisions Down

Architecture knowledge decays when it lives only in people’s heads. Architecture decision records (ADRs) are short documents, one per decision, kept next to the code:

# 7. Orders own the order data
 
Status: accepted · 2026-08-12
 
## Context
Payments and shipping both write to the orders table, so schema changes need three teams.
 
## Decision
Only the orders service writes order data. Others read through its API or the
"order placed" and "order updated" events.
 
## Consequences
Payments and shipping change independently. We accept eventual consistency
(up to a few seconds) in the shipping dashboard.

Three sections are enough: context (why now), decision (what), consequences (what we accept). The consequences section is the most valuable part a year later.

Going Deeper: Teams, Guardrails and Changing Data

Architecture Mirrors the Organization

Melvin Conway observed in 1968 that systems end up mirroring the communication structure of the organizations that build them. Two teams that rarely talk produce two systems with a thin, formal interface; one team that owns everything produces a system with no internal boundaries at all.

The practical consequence is sometimes called the inverse Conway manoeuvre: design the teams you need for the architecture you want.

• Organize stream-aligned teams, each owning a business capability end to end, with a cognitive load small enough to genuinely own it.
• Don’t split one team’s system into ten services. That only adds network calls.
• Don’t spread one capability across services owned by others. That creates a distributed monolith.

Encode Boundaries as Tests

Boundaries agreed in a meeting erode one convenient import at a time. Senior engineers turn them into fitness functions: automated checks that fail the build when the architecture drifts.

• Dependency rules: “nothing outside payments/ imports payments/internal”, enforced with tools such as dependency-cruiser (JavaScript and TypeScript) or ArchUnit (Java).
• Ownership: every directory has a code owner who reviews changes to it.
• Budgets: a page’s JavaScript size, a service’s p99 latency or the number of synchronous calls on a critical path, checked in CI or by monitoring.

Change Data Without Downtime

Data models are the hardest one-way doors, because data outlives code. The safe way to change a schema shared by running services is expand and contract (also called parallel change), where every step is backward compatible and can be deployed and rolled back on its own:

It takes more deployments than a single migration, but at no point do old and new code disagree about the data, which is what makes the change reversible.

Signs Your Architecture Is Fighting You

• A small feature needs changes in many services, or many teams in the same release.
• People are afraid to change a shared library or table.
• You can’t run or test one part without starting the whole system.
• Incidents spread: one slow service makes unrelated features fail (more on this in distributed systems fail in the gaps between teams).
• “Temporary” workarounds outlive the people who wrote them (see technical debt is not the enemy).

Test Yourself: Scenarios

Think through your answer, then compare.

Key Takeaways

Sources

• Martin Fowler: Conway’s law and Parallel change
• Matthew Skelton and Manuel Pais: Team Topologies, key concepts
• Thoughtworks Technology Radar: Architectural fitness function
• dependency-cruiser and ArchUnit
• Nicole Forsgren, Jez Humble and Gene Kim: Accelerate (IT Revolution, 2018), and DORA: Loosely coupled teams
• David L. Parnas: On the criteria to be used in decomposing systems into modules (1972)
• Michael Nygard: Documenting architecture decisions
• Jeff Bezos, 2015 letter to Amazon shareholders, on Type 1 and Type 2 decisions, summarized with quotes by Farnam Street: Reversible and irreversible decisions
• Sam Newman: Monolith to Microservices (O’Reilly, 2019)
• InfoQ: Segment’s move from microservices back to a monolith (2018), summarizing Alexandra Noonan’s “Goodbye microservices”
• InfoQ: Prime Video’s monitoring service moving from serverless to EC2 and ECS (2023)
• Martin Fowler: Monolith first