Distributed Systems Patterns

Read-only pattern skill. Use the caller's stage and output contract. Implementation requires an authorized implementation request.

Two bodies of knowledge, one skill. The topology routes are grounded in Burns, Designing Distributed Systems: containers plus an orchestrator give a shared language for reusable distributed pieces — name the pattern, then reuse or compose it. The event-driven route is grounded in Bellemare: a durable, replayable data communication layer of schematized event streams, not point-to-point messages that vanish after consume. Do not invent a one-off topology the catalog already names, and do not call a delete-after-consume queue an event architecture.

Outcome

• Result: a brief with one named pattern (or an explicit compose of two), or — on the event-driven route — one verdict, plus the next concrete move.
• Next consumer: the user for a standalone brief, or the calling workflow through its existing decision or gate contract.
• Done: every required field of the selected output contract is filled; the pattern is from the selected method's catalog; every load-bearing claim cites repo evidence or is marked assumed; a consequential unresolved choice includes a rejected alternative; the next move is one action.
• Intent: stop four failures — reinventing a named primitive; applying a multi-node pattern when a coscheduled pair would do (or an election when a singleton would do); adopting event-driven microservices when a modular monolith is cheaper; and building them without a data communication layer (implicit schemas, shared DBs, CDC as the destination).

Select the route