The Microservices Distillation: Independent Deploy, Team-Owned, Bounded

What This Concept Is

A microservice is a service that satisfies three hard criteria at once:

• Independently deployable. You can release it without coordinating a deploy of any other service.
• Team-owned. A single team owns the code, the data, the runtime, and the on-call rotation for that service end-to-end.
• Modeled around a business capability. It represents one bounded slice of the business -- not a layer, not an entity, not a utility.

Everything else ("small", "REST", "Docker", "Kubernetes", "polyglot") is an implementation detail. If the three criteria above are not true, it is a distributed system, but it is not a microservice.

Why It Matters Here

The single most common expensive mistake in this space is to call something a microservice that does not satisfy these criteria. Teams then pay every cost of distribution (network, serialization, partial failure, operational overhead) and get almost none of the benefits (independent evolution, team autonomy, fault isolation).

When you are accused of "building a distributed monolith" later in the module, the diagnostic is exactly that one of these three criteria has quietly failed.

Concrete Example

Consider an online retailer. A candidate decomposition:

• Catalog Service -- owns product data, categories, media URLs. Database: catalog_db.
• Inventory Service -- owns stock-on-hand, reservations, warehouse assignments. Database: inventory_db.
• Orders Service -- owns order lifecycle and line items. Database: orders_db.

Each service is deployed on its own pipeline. Each team can ship multiple times a day without asking another team. Each service has a business purpose a product manager would recognize.

Now contrast with a common failure: a "Product Service" that both catalog and inventory teams have commit rights to, backed by a shared product_db, released behind a single coordinated deploy. That is not a microservice -- it is a shared library with a network hop in front of it.

Common Confusion / Misconception

"Microservices means small." Size is a consequence of the criteria, not the cause. A 40k-line service that one team owns, deploys independently, and aligns to a business capability is still a microservice. A 500-line service that cannot ship without coordinating with two other teams is not.

The second common confusion: treating every noun as a service (Customer Service, Order Service, Address Service). That produces entity services, covered in concept 06.

How To Use It

When you are asked "is this a microservice?", run the checklist:

1. Can this service be deployed without a simultaneous deploy of any other service?
2. Does exactly one team own its code, data, tests, and runtime?
3. Can a non-engineer name the business capability it delivers?

If the answer to any of these is no, something needs to change before the label applies. Either fix the coupling, consolidate ownership, or accept that this is part of a larger unit and merge it.

Check Yourself

1. Why is "it has its own Docker image" not enough to call something a microservice?
2. If two services cannot be deployed independently, which of the three criteria has failed?
3. Why does team ownership matter for a property that otherwise sounds purely technical?

Mini Drill or Application

Pick a system you know (work, side project, or the e-commerce example above). For each candidate service, write a two-column table:

| Service | Deploys alone? | One team? | Business capability in one sentence? |

Mark each cell yes/no/unclear. Any service with unclear or no in any column is a candidate for rework, merge, or rename. Do this in 10 minutes.

How This Sits In The Module

The rest of the module is a field guide for making these three properties true: cluster 2 makes the boundary work, cluster 3 makes ownership real at the data level, cluster 4 makes independent deployment survive network realities, and cluster 5 operates the result.

Transfer: Where Else These Three Properties Apply

The three properties (independent deployability, one-team ownership, bounded capability) are not microservices-specific. They apply to:

• Modular monoliths with internal module teams. Same test, weaker guarantees (one process, but module boundaries still enforced by linters and ArchUnit-style fitness functions from S7 M5 concept 13).
• Serverless functions. A lambda that one team owns end-to-end and that implements one business capability is a microservice by these criteria, even if it is 200 lines.
• Data pipelines / batch jobs. A scheduled job with a dedicated team and a bounded output is a "microservice" in all but the request-response shape. The on-call, versioning, and contract disciplines still apply.

If you want to reason about whether any distributed unit in your system is well-defined, run the three-property audit on it.

Connecting Back to Architecture Styles

Fundamentals of Software Architecture (Richards & Ford) frames microservices as one point in a two-axis space: partitioning (technical vs domain) and granularity (monolithic vs distributed). See FoSA: Architecture Styles and FoSA: Choosing the Appropriate Architecture Style. Microservices occupy the "domain-partitioned + highly distributed" corner -- which is exactly what the three properties encode. Every other style relaxes at least one of them.

The book's "Monolithic vs Distributed" chapter (030) is the precise text to read if a stakeholder asks "why not just a big service?" The answer they give in one sentence: distribution buys independence, and independence is only worth buying when the three properties above are non-negotiable for your team.

Check Yourself (Extended)

4. A service has its own repo, its own database, its own pipeline -- but every deploy requires a "release coordination doc" because a shared serialization library needs a lockstep bump. Which of the three criteria is violated? (Answer: independent deployability; the shared library is a hidden coupling. See concept 06.)
5. Two teams equally commit to one service because "they both need to ship to it." Which criterion fails and what is the fix? (Answer: team ownership; either split the service along the stream lines or merge the teams.)
6. A service called UtilityService stores shipping labels, auth tokens, and email templates because "they're all stateless helpers." Which criterion fails? (Answer: bounded business capability; the service has no cohesive purpose. See concept 06's nano-service anti-pattern.)

Read This Only If Stuck

Local chunks (book anchors)

• System Design Primer: Application Layer, Microservices, and Service Discovery -- the short-form microservices section; read the "advantages/disadvantages" list in full.
• FoSA: Monolithic vs Distributed Architectures -- locates microservices among distributed styles.
• FoSA: Architecture Styles -- the full style catalog.
• FoSA: Choosing the Appropriate Architecture Style -- the selection framework; apply it before committing.
• FoSA: Modularity and FoSA: Measuring Modularity -- the coupling metrics that independently-deployable services must satisfy (low afferent + efferent coupling across the service boundary).

External canonical references

• Martin Fowler and James Lewis, Microservices -- the canonical definition piece; read "Characteristics of a Microservice Architecture" (the 9-point list) in full.
• Sam Newman, What are microservices? (samnewman.io) -- the 7 principles from Building Microservices 2e, in one page.
• Chris Richardson, What are microservices? (microservices.io) -- the pattern-catalog entry with the strict definition and known uses.
• ThoughtWorks Technology Radar, Microservices architecture (multiple entries, 2014-present) -- the radar's shifting position shows how maturity of the style evolved.
• Martin Fowler, Microservice Prerequisites -- the capabilities you must have before the three properties can hold.

Depth Path

• Chris Richardson's microservices.io pattern index is the map you will come back to for the rest of the module.
• Sam Newman, Building Microservices (2nd ed.), chapter 1 -- the fullest treatment of the definition and its consequences; 45 minutes of focused reading covers it.

Worked Example: The Three-Property Audit

Take a real service from a system you know and score it against the three criteria. Be specific.

Criterion	Evidence that it holds	Evidence that it fails
Independently deployable	Separate CI pipeline, separate artifact, can roll out without other deploys	Shared DTO jar, shared DB migrations, "release train" on a fixed date
Team-owned	One team's name on the runbook, one on-call rotation, one backlog	Multiple teams commit to the repo; unclear who owns the pager
Bounded business capability	A product manager can name what it does in one sentence	Name is "Utility Service" or "Common"; purpose is "stuff we share"

If any column on the right applies, fix that specific problem before calling the service a microservice.

Why All Three Criteria, Not Just One

Each criterion alone is insufficient:

• Independent deploy without team ownership gives you a service no one is accountable for.
• Team ownership without independent deploy gives you a module branded as a service.
• Business-bounded scope without team ownership gives you a nice concept with no author.

The three criteria compose: ownership makes deploy independence actionable; scope makes ownership meaningful; deploy independence makes the whole thing observable from outside.

How This Connects Across the Module

Module cluster	Makes which criterion real
Cluster 2: boundaries	"Bounded business capability" -- gives the scope a principled basis
Cluster 3: data + contracts	"Independently deployable" -- prevents silent coupling through shared data
Cluster 4: communication	"Independently deployable" -- survives the network realities that otherwise break it
Cluster 5: operations + topology	"Team-owned" -- makes ownership observable and enforceable

Keep this map handy. Whenever a later concept feels abstract, trace it back to which property it is protecting.