A team says "we use microservices" and another says "a change to the pricing rule touches one deployable and one team". Why does the second sentence tell you more about the architecture than the first, and what three properties should you ask about instead of the style name?

What the style name does and does not carry

A style name describes how the system is packaged and deployed. It says nothing about whether the boundaries inside it are drawn where change arrives. Two estates can both be "microservices" and behave in opposite ways: one where adding a currency touches one service, and one where the same change touches nine services, three teams and a coordinated release.

The style is a packaging decision; the architecture is the set of properties that packaging produced. That is why "we use microservices" is close to unfalsifiable, while the second sentence is a claim you can test against the last twenty merged changes.

The three properties worth asking about

Change locality — for the next ten changes you expect, how many deployables and how many teams must agree? One team and one deployable means the boundary matches the work. The usual warning sign is a feature that needs a release plan. Measure it from version-control history rather than from a diagram: the set of services whose files change in the same pull request is the honest coupling graph.

Failure locality — when one component fails, what fraction of users notice, and does the failure stay where it started? A system of fifty services behind one synchronous call chain has the failure locality of a single machine, because a serial dependency chain multiplies unavailability: four hops at 99.9% each give about 99.6%, roughly 3 hours of downtime a month rather than 43 minutes.

Scaling locality — can the expensive path be given more resources without also multiplying the cheap paths? A monolith where image processing shares a thread pool with checkout has no scaling locality, and the symptom is that a batch of uploads causes a checkout incident.

Why this framing matters for a beginner

These three questions are answerable about a system you have never seen, from its commit history, its dependency graph and one incident review. The style name is answerable from a README and predicts almost nothing.

It also removes the false choice. A modular monolith with enforced internal boundaries can have excellent change locality and poor failure isolation; a microservice estate can have the reverse. Naming the properties you need lets you buy only the ones you need.

When the style name is the right thing to say

In two situations. When you are describing operational shape to someone who has to run it — how many deployables, how they are released, what the on-call surface is — the style name is the useful summary. And when a style carries a hard constraint: "space-based" tells an operator that state lives in a replicated in-memory grid, which decides the failure modes they must plan for.

Common weak answers

• "Microservices are better for scale." Scale is three different properties and the sentence names none of them. Independent deployability is the usual reason to distribute, and it is an organisational property, not a throughput one.
• "It depends on the team size." True and unusable. Team size matters because it changes coordination cost, so say that: more teams per change means longer lead time, and the fix is moving the boundary, not adding process.
• Describing the diagram. A box count is not a property. Two estates with identical diagrams can differ by an order of magnitude in change locality.