There is no default architecture

Every architecture conversation I get called into has already had its answer decided before I arrive. Not by analysis — by fashion, or by whatever the last conference talk said, or by a senior engineer’s last job. The answer arrives first and the reasoning is assembled behind it.

The reasoning is usually good. That is what makes it hard to argue with. What is missing is not logic, it is the step before logic: nobody wrote down the constraints.

The question that reorders the room

When a team tells me they are going with microservices, I ask one thing: who deploys this on a Wednesday afternoon when something is wrong?

Not “can we scale it”. Everyone can answer that; the answer is always yes. The Wednesday question is different, because it is about the system as it will actually be operated, by the people who will actually operate it, on the day nobody planned for.

The answers are revealing. Sometimes it is a platform team of six with an on-call rotation, and microservices are a reasonable answer to a real coordination problem. More often it is two developers, one of whom also does the frontend, and the honest answer is nobody, and we would find out on Thursday.

That is not an argument against distribution. It is an argument that distribution has an operational cost, that cost is paid by specific named people, and it should be on the table next to the benefit.

What the constraints actually are

In small and mid-size companies, the constraints that decide the architecture are almost never the ones in the architecture diagram. They are:

• How many people will maintain this, and for how long. A design that needs four engineers to stay coherent will rot with two.
• What the company already runs. There is an ERP, an accounting package, a CRM. They are load-bearing. Any design that assumes they can be replaced is a design for a different company.
• What the infrastructure budget actually is. Not the aspirational figure — the one on the invoice.
• How fast the domain changes. A stable domain tolerates rigid boundaries. A domain that is still being discovered punishes them, because you draw them in the wrong place and then defend the mistake.

Notice that none of these is technical. Which is why an architecture chosen on technical grounds alone is usually chosen on the wrong grounds.

Four shapes, and when each one earns its place

A modular monolith. Clear internal boundaries, one deployable unit, one database to reason about. This is the correct default far more often than it gets credit for, and it is the shape I most often argue for against a team that has already decided otherwise. Its real advantage is not simplicity — it is that the boundaries are cheap to move. You drew them wrong; you will draw them wrong; in a monolith that is a refactor rather than a migration.

Service-oriented. Services split along ownership lines, with contracts versioned deliberately. This earns its place when several teams’ release cadences have started to collide — when the coordination cost of a shared deployment has become larger than the operational cost of separate ones. That is a real threshold and it is crossable. It is just much further away than most teams think.

Event-driven. Systems emit events; reactions are decoupled from what caused them. This is the right shape when a process genuinely spans tools nobody wants to couple — where the alternative is a web of point-to-point integrations that nobody can draw on a whiteboard. It is the wrong shape when it is applied uniformly, as ceremony around calls that are synchronous in every meaningful sense.

A data and ML pipeline. Ingestion, preprocessing, training, serving, each observable on its own. When the product is the prediction, this is not one architecture among several — it is the shape of the problem. The failure here is treating the model as the system and the pipeline as plumbing, which is backwards: the pipeline is where reproducibility lives, and without reproducibility a model is an anecdote.

The part that is not architecture

Most of what gets argued about as architecture is really a question about the organisation. Conway’s law is usually quoted as an observation, but it works better as a design constraint: if you are not willing to change who talks to whom, you are not free to choose any shape you like.

So the useful sequence is: constraints first, then organisation, then shape. Doing it in the other order produces a diagram everyone agrees with in the meeting and nobody can operate on a Wednesday.

What I actually recommend

Start with the smallest shape that can carry the constraint you know you have, and design the boundaries so a bigger shape stays reachable. Concretely, that usually means: one deployment, real internal boundaries, no module reaching into another’s data, and integration through explicit contracts.

That posture costs almost nothing to hold and it keeps every door open. Extraction into a service later is an evolution of a module that already had a boundary. Extraction from a monolith with no boundaries is a rewrite, and it is the reason so many microservice migrations end up as a distributed version of the same mess.

There is no default architecture. There is only the smallest one that survives your constraints — and the discipline to write those constraints down before anybody draws a box.