Q44 proof · Microservices architecture: decomposition, data ownership, independent deployability

44. Microservices architecture, and how many years

Answer as submitted

“Yes — I have worked with microservices architecture for 6+ years, and with service-oriented/distributed integration for considerably longer.”

Technical decision: expand. A year count alone is not checkable, so this page states what the count is counted from and then shows the architecture itself: where the boundary is drawn, why data ownership is the line that decides whether the style works, and how independent deployability is demonstrated instead of asserted.

Expanded answer

Yes — 6+ years with microservices as the delivery model, counted from the first service that had its own pipeline and its own database, plus a considerably longer period of service-oriented, message-driven integration before that, which is where the contracts, the idempotency and the failure-handling habits came from. The distinction matters, because a monolith behind an API gateway is not a microservice architecture and the years should not be counted from the first REST call. On the architecture itself: the boundary is drawn where the language changes and the transaction ends, a bounded context that owns its rules and its data becomes a service, and granularity is decided by the transaction that must stay atomic together with the team that must be able to deploy it — because both errors, too coarse and too fine, produce the same failure, a distributed monolith where everything ships together anyway. Data ownership is the line that decides whether the style works: one writer per data store, no cross-service joins, and other services reading through the contract or maintaining their own projection, which is what makes independent deployment possible rather than merely intended. Independent deployability is then demonstrated rather than claimed: one pipeline per service, consumer-driven contract tests that the provider verifies in its own build, and rolling, blue-green or canary releases chosen by the blast radius — if two services must be released together, that is a boundary defect and it shows up in the release manifest. Operations carry the same weight as the code: containers orchestrated with declared probes and limits, autoscaling on the signal that predicts load, secrets in a manager and rotated, and one correlation id across centralised logs, metrics and traces. And the boundaries are enforced mechanically, because the first urgent ticket is what removes them otherwise: an assembly reference between two services, a shared domain library and a public database context are all things a test refuses.

Period	What the work was	What it demonstrates
2020 → present (6+ years)	microservices as the delivery model: bounded contexts, per-service data stores, per-service pipelines, sagas and the outbox for cross-context flows, containers on Kubernetes/ECS/AKS	designing, shipping and operating services that are released independently
Before 2020	service-oriented and message-driven integration: enterprise middleware, MQ systems, scheduled and batch processing, contracts between systems owned by different teams	the contracts, idempotency and failure-handling habits that microservices then reused
What does not count	a monolith behind a gateway, or services that share a database and a release train	the distinction the count is meant to make

Axis	Decision	Distributed-monolith smell it prevents
Decomposition	one bounded context per service, granularity by transaction and team	chatty services that only work together
Data ownership	one writer per store, no cross-service joins, contracts instead of schemas	a shared database with a join, which couples every release
Contracts	versioned interfaces and events; no shared domain library	a package that forces every service to redeploy together
Delivery	one pipeline per service, contract tests verified by the provider, canary gates	lockstep releases and a deploy window everybody waits for
Operations	probes, limits, autoscaling, secrets management, tracing with one correlation id	a release that needs somebody who knows the environment by heart
Enforcement	architecture tests over assembly references and a private database context	the boundary being removed one urgent ticket at a time

Live microservices workflow proof

The running component below changes its axis/result view through real event binding. Select an axis to see the decision, the reasoning behind it, and the evidence that it holds.

MICROSERVICES WORKFLOWRUNNING

Choose an axis of the microservice architecture

Select an axis to inspect the decision, the reasoning and the evidence.

$ one bounded context per service · a business capability as the boundary · granularity decided by transaction and team, not by fashion

The boundary is drawn where the language changes and the transaction ends: a bounded context that owns its rules and its data becomes a service, and a capability one team can own end to end becomes its unit of delivery. Granularity is decided by the transaction that has to stay atomic and by the team that has to be able to deploy it, because the failure mode in both directions is the same one: a distributed monolith where everything is deployed together anyway.

services drawn around a bounded context: all
services sharing a transaction with another service: 0
distributed monolith smells tracked: 3 (chatty calls, lockstep deploys, shared-library churn)
granularity revisited when two services always change together: yes

What the architecture buys — and what it costs

Rules I apply. Draw the boundary where the transaction ends and the language changes, then let one team own the service end to end, because a boundary that does not match an owner becomes a coordination cost; give each service its own data and refuse the join, since a shared database is a distributed monolith with a nicer diagram; publish versioned contracts rather than sharing types, because a shared library couples deployments through a package; verify your consumers' expectations in your own pipeline, so a breaking change fails in your build instead of in somebody else's production; enforce the boundary with a test over assembly references, because otherwise the first urgent ticket removes it; and accept the cost honestly — more infrastructure, more observability and more failure modes than a modular monolith, which is why I do not reach for microservices until the team count and the deployment independence justify them.

Boundary for Q44: this page covers the microservice architecture itself — boundaries, data ownership, independent deployability and operations. Service-to-service communication, API gateways, authentication and service discovery between them are the subject of the Q45 question; the runtime behaviour of a distributed system is on Q34; consistency across services is on Q35; and the pattern choice itself is on Q30.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the others are the service catalogue that makes the claims checkable, the inside of one service with its boundary tests, and the contract tests that demonstrate independent deployability.

Acceptance criteria

Answers the years question with a condition the claim is counted from, not just a number.
Names the boundary rule and the granularity decision behind the decomposition.
Shows an interactive proof of choosing an axis and reading the evidence.
Gives each service its own data and refuses cross-service joins and lockstep releases.
Demonstrates independent deployability with contract tests and enforced boundaries, and states the cost.