Distributed Systems Patterns

Read-only pattern skill. Do not implement unless the user asks after the brief.

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, or design-gate / coding-design-plan after they accept the brief.
• Done: every required brief field is filled; the pattern is from the selected method's catalog; every load-bearing claim cites repo evidence or is marked assumed; at least one rejected alternative is named; 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