Building Microservices¶
Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems. O'Reilly Media.
Cited by¶
10 citations across 10 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Coarsening
- Software architecture: small services consolidate when per-service overhead (separate deployment, monitoring, on-call) is high relative to the service's own work, structurally the same as grain coarsening.
This sourceTreats per-service overhead (deployment, monitoring, on-call) versus the service's own work, and bounded contexts as the boundary that prevents over-consolidation.
- Software architecture: small services consolidate when per-service overhead (separate deployment, monitoring, on-call) is high relative to the service's own work, structurally the same as grain coarsening.
- Design Patterns
- In architecture, professional gatekeeping (licensing, regulation), construction economics (one-time, physical, expensive), and path-dependent cultural preferences—of the kind Jacobs (1961) catalogued in The Death and Life of Great American Cities, where top-down planning orthodoxies overrode pattern-language fitness—have limited pattern-language adoption despite intellectual influence.
This sourceTreats microservice granularity and inter-service coordination cost as tunable design parameters. Cited inline in §5, §9, and the example (tier B — supports the incremental-microservices-decomposition claim).
- In architecture, professional gatekeeping (licensing, regulation), construction economics (one-time, physical, expensive), and path-dependent cultural preferences—of the kind Jacobs (1961) catalogued in The Death and Life of Great American Cities, where top-down planning orthodoxies overrode pattern-language fitness—have limited pattern-language adoption despite intellectual influence.
- Holarchy
- Service-oriented and microservice architectures are in effect engineered holarchies: each service hides its internals and presents a stable contract upward.
This sourceCanonical treatment of microservice architecture: partitions an application into independently deployable services each owning one narrow concern, and frames service granularity (and the coordination cost of inter-service calls) as a tunable design parameter — the computing instance of optimal-partition-depth reasoning.
- Service-oriented and microservice architectures are in effect engineered holarchies: each service hides its internals and presents a stable contract upward.
- Interfacial Energy
- The surfactant-class agent is any shared protocol library, code-generation tool, or standardized RPC framework (gRPC, a shared schema registry) that lowers the per-seam cost and makes finer subdivision viable.
This sourceTreats inter-service call overhead (serialization, network latency, schema coordination) and shared tooling/RPC frameworks that lower the per-seam cost of service boundaries.
- The surfactant-class agent is any shared protocol library, code-generation tool, or standardized RPC framework (gRPC, a shared schema registry) that lowers the per-seam cost and makes finer subdivision viable.
- Modularity
- Newman's 2015 microservices analysis catalogs these failure modes systematically: low coupling at the interface level does not entail loose coupling at the system level.
This sourceCatalogs hidden runtime coupling modes — timing, resource availability, data consistency, operational context — that can defeat apparent low interface coupling in distributed module architectures.
- Newman's 2015 microservices analysis catalogs these failure modes systematically: low coupling at the interface level does not entail loose coupling at the system level.
- Pipeline
- Registry-Mediated Discovery
- Versioning
- Listed in the references but not attached to a specific claim.
Mechanisms¶
- Capped-Growth or Split Rule
- That is the distributed-monolith trap
This sourceWarns that chatty service communication creates tight coupling, undermining independent change and deployment-the central benefit of microservice boundaries.
- That is the distributed-monolith trap
- Service Decomposition
- Split along the wrong boundaries — or leave services sharing a database and calling each other constantly — and you get a "distributed monolith": all the operational cost of distribution with none of the independence, because the pieces still can't deploy or scale apart.
This sourceWarns that poor service boundaries and coupling sacrifice autonomy while retaining distributed-system complexity, and treats independent deployment and scaling as central benefits that coupled services lose.
- Split along the wrong boundaries — or leave services sharing a database and calling each other constantly — and you get a "distributed monolith": all the operational cost of distribution with none of the independence, because the pieces still can't deploy or scale apart.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 10 citations of this work carries a recorded support check.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:3753edde777d · see in the full table