Microservices Patterns¶
Garcia-Molina, H., & Salem, K. (2018). Microservices Patterns: With Examples in Java. Manning.
Retired. This entry was not a citation. Our extractor stored an inline prose definition from the article as though it were a bibliographic record: the title names a concept rather than a published work, and the citation text names no work at all. The page is kept because links to it still resolve, but it is withdrawn from the reference list. This entry is kept so the citations that pointed at it still resolve, and so the correction is visible rather than silent.
Cited by¶
11 citations across 11 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Design Patterns
- Modern software architecture practice operates on a richly elaborated pattern language at multiple compositional scales, with canonical catalogs at each level: Fowler (2002) at the enterprise application tier, Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996) plus Schmidt, Stal, Rohnert, and Buschmann (2000) for architectural and concurrent/networked patterns (POSA1 and POSA2), and Newman (2015) and Richardson (2018) for microservices.
This sourceManning. Comprehensive 44-pattern catalog for microservices (Saga, CQRS, Event Sourcing, API Gateway, Service Discovery, Circuit Breaker).
- Modern software architecture practice operates on a richly elaborated pattern language at multiple compositional scales, with canonical catalogs at each level: Fowler (2002) at the enterprise application tier, Buschmann, Meunier, Rohnert, Sommerlad, and Stal (1996) plus Schmidt, Stal, Rohnert, and Buschmann (2000) for architectural and concurrent/networked patterns (POSA1 and POSA2), and Newman (2015) and Richardson (2018) for microservices.
- False Dilemma
- Product and engineering design — "should we build A or B?" suppresses smaller versions of both, hybrids, do-nothing, and reframings of the underlying need. Software architecture — "microservices or monolith," "SQL or NoSQL," which crowd out modular monoliths, polyglot persistence, and staged migrations.
This sourceCatalogs 44 patterns for service decomposition and monolith refactoring, treating monolith-versus-microservices as a design spectrum (including the modular monolith and staged migration) rather than a binary, supporting the software-architecture use.
- Product and engineering design — "should we build A or B?" suppresses smaller versions of both, hybrids, do-nothing, and reframings of the underlying need. Software architecture — "microservices or monolith," "SQL or NoSQL," which crowd out modular monoliths, polyglot persistence, and staged migrations.
Mechanisms¶
- API Gateway
- The gateway is a single point of failure
This sourceTreats the API gateway as the single entry point for external requests and notes that its unavailability blocks external access to backend services.
- The gateway is a single point of failure
- Deduplicating Message Consumer
- Its strength is converting an at-least-once channel into effectively-once processing at the one place it matters — the effect boundary — with nothing more than a remembered set of identities.
This sourceExplains how an idempotent consumer handles at-least-once delivery by recording processed message identifiers and discarding duplicates.
- Its strength is converting an at-least-once channel into effectively-once processing at the one place it matters — the effect boundary — with nothing more than a remembered set of identities.
- Dual-Write Outbox and Inbox Pattern
- Because the obligation to propagate is committed atomically with the change itself, no partial failure can silently drop or fabricate an update — the outbox is the durable record of intent and the inbox the durable record of receipt.
This sourceThe cited work establishes the obligation to propagate is committed atomically with the change itself and the outbox is the durable record of intent.
- Because the obligation to propagate is committed atomically with the change itself, no partial failure can silently drop or fabricate an update — the outbox is the durable record of intent and the inbox the durable record of receipt.
- Event Choreography
- The classic misuse is reaching for choreography where the job actually wants a linear, auditable transaction with a clear owner — that is orchestration's territory, and forcing it into choreography trades a legible process for invisible coupling.
This sourceContrasts hard-to-follow, coupled choreography with the linear, centralized control supplied by orchestration.
- The classic misuse is reaching for choreography where the job actually wants a linear, auditable transaction with a clear owner — that is orchestration's territory, and forcing it into choreography trades a legible process for invisible coupling.
- Outbox Deduplication
- Writing state and intended messages in one transaction is the well-known transactional outbox pattern, and it is the standard way to get reliable, once-per-operation messaging without a distributed transaction spanning the database and the message bus.
This sourceA transactional outbox atomically records state and intended messages without a database-to-broker distributed transaction, but consumers must handle possible duplicate publication.
- Writing state and intended messages in one transaction is the well-known transactional outbox pattern, and it is the standard way to get reliable, once-per-operation messaging without a distributed transaction spanning the database and the message bus.
- Saga Choreography
- Its strength is loose coupling and autonomy
This sourceDescribes choreography-based sagas as loose event coordination without a central coordinator, allowing services to evolve and deploy independently.
- Its strength is loose coupling and autonomy
- Transactional Outbox
- Transactional Outbox/Inbox Relay
- The classic misuse is assuming the outbox delivers exactly-once end-to-end and skipping the inbox dedup, which reintroduces the double-processing it was supposed to prevent.
This sourceExplains that transactional outbox delivery is at least once and therefore requires consumer-side idempotency or deduplication to prevent double processing.
- The classic misuse is assuming the outbox delivers exactly-once end-to-end and skipping the inbox dedup, which reintroduces the double-processing it was supposed to prevent.
- Transactional Outbox Projection
- Its strength is closing the dual-write problem
This sourcePresents transactional outbox as a solution to dual writes: store a message in the same database transaction as business data, avoid 2PC, and publish messages iff that transaction commits.
- Its strength is closing the dual-write problem
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 11 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.
Links previously used in the corpus¶
Before the registry existed this work was also linked 3 other ways.
- https://www.manning.com/books/microservices-patterns ×9
- https://www.manning.com/books/microservices-patterns?id=882 ×1
- https://www.oreilly.com/library/view/microservices-patterns/9781617294549/ ×1
Registry ID ref:266725f06cfd · see in the full table