distributedlisted

# Distributed -- Distributed Systems Design ## Activate When - User invokes `/godmode:distributed` - User says "distributed system", "CAP theorem", "consensus protocol" - User says "Raft", "Paxos", "leader election", "distributed lock" - User says "sharding", "partitioning", "eventual consistency" - User says "split brain", "network partition", "quorum" - When designing systems that span multiple nodes or data centers - When `/godmode:plan` identifies distributed architecture work - When `/godmode:review` flags consistency or partition tolerance issues ## Workflow ### Step 1: Distributed System Context Understand the system before making distributed design decisions: ``` DISTRIBUTED SYSTEM CONTEXT: Project: <name and purpose> Topology: Single Region | Multi-Region | Edge | Hybrid Number of Nodes: <expected cluster size> Data Model: Relational | Document | Key-Value | Graph | Time-Series Consistency Requirement: Strong | Eventual | Causal | Session Availability Requirement: <target uptime, e.g., 99.99%> Partition Tolerance: Must handle network partitions | Single data center only ... ``` If the user has not provided context, ask: "What is the consistency requirement -- do all reads need to see the latest write, or is stale data acceptable for a bounded time? This is the most important distributed systems decision." ### Step 2: CAP Theorem Trade-Off Analysis Analyze the fundamental trade-offs for the system: ``` CAP THEOREM ANALYSIS: | CONSISTENCY | | /\ | | / \ | | / \