distributed-systems-patterns

# Distributed Systems Patterns Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178. <!-- dual-compat-start --> ## Use When - Use when designing or reviewing multi-service, message-driven, or eventually consistent systems. Covers service boundaries, consistency tradeoffs, event workflows, outbox and inbox patterns, sagas, ordering, and idempotency. ## Do Not Use When - The change is a single-process transaction with no remote dependency, asynchronous delivery, or independently failing component. - The task is mainly service decomposition or API shape; use `system-architecture-design` or `api-design-first` and return here for cross-boundary failure semantics. ## Required Inputs | Input | Required | Why it matters | |---|---|---| | Workflow steps and system boundaries | yes | Identifies where atomicity ends and partial failure begins | | Delivery, ordering, and consistency requirements | yes | Determines idempotency, sequencing, and reconciliation choices | | Failure and recovery expectations | yes | Sets timeout, retry, compensation, and operator intervention rules | | Throughput and latency constraints | conditional | Tests whether the coordination pattern is viable | ## Workflow Draw state transitions and ownership boundaries, enumerate failure windows, choose consistency and coordination patterns, define idempotency and recovery, then verify duplicate, reordered, delayed, and partially applied events. ## Quality Standards Every remote int...