distributed-patternslisted

Use when designing distributed systems or evaluating distributed architecture patterns. Covers CAP theorem trade-offs, consensus protocols (Raft, Paxos), saga orchestration, CRDTs, event sourcing, partition handling, distributed transactions, and failure detectors. Do not use for general API design (use api-design) or database schema design (use schema-design).
dtsong/my-claude-setup · ★ 5 · AI & Automation · score 76

Install: claude install-skill dtsong/my-claude-setup

# Distributed Patterns ## Purpose Evaluate distributed system design decisions and recommend appropriate patterns for consistency, availability, partition tolerance, and failure handling. Ensure designs account for the fundamental constraints of distributed computing. ## Scope Constraints Analyzes architecture documents, system diagrams, and code for distributed system patterns. Does not modify files or execute code. Does not benchmark or load-test distributed systems. ## Inputs - System architecture overview (services, data stores, communication patterns) - Consistency requirements (strong, eventual, causal) - Availability and latency SLAs - Expected failure modes and partition scenarios - Current distributed patterns in use, if any ## Input Sanitization No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets. ## Procedure ### Progress Checklist - [ ] Step 1: Classify CAP trade-offs - [ ] Step 2: Evaluate consistency patterns - [ ] Step 3: Design failure handling - [ ] Step 4: Review data synchronization - [ ] Step 5: Assess transaction patterns - [ ] Step 6: Validate operational readiness ### Step 1: Classify CAP Trade-offs - Identify each service's position on the CAP spectrum. - Map which data requires strong consistency vs eventual consistency. - Document partition behavior: does the system favor CP or AP per data domain? - Flag services that implicitly assume no partitions (single-region, no failover).