designing-distributed-systems

Name: designing-distributed-systems
Author: ancoleman

78installs59forks

How to install designing-distributed-systems?

ancoleman/ai-design-components/designing-distributed-systems

$npx -y skills add ancoleman/ai-design-components --skill designing-distributed-systems

Installs into the current project.

Summary

When designing distributed systems for scalability, reliability, and consistency. Covers CAP/PACELC theorems, consistency models (strong, eventual, causal), replication patterns (leader-follower, multi-leader, leaderless), partitioning strategies (hash, range, geographic), transa

Files · 1

View on GitHub

SKILL.md

1	# Designing Distributed Systems
2
3	Design scalable, reliable, and fault-tolerant distributed systems using proven patterns and consistency models.
4
5	## Purpose
6
7	Distributed systems are the foundation of modern cloud-native applications. Understanding fundamental trade-offs (CAP theorem, PACELC), consistency models, replication patterns, and resilience strategies is essential for building systems that scale globally while maintaining correctness and availability.
8
9	## When to Use This Skill
10
11	Apply when:
12	- Designing microservices architectures with multiple services
13	- Building systems that must scale across multiple datacenters or regions
14	- Choosing between consistency vs availability during network partitions
15	- Selecting replication strategies (single-leader, multi-leader, leaderless)
16	- Implementing distributed transactions (saga pattern, event sourcing, CQRS)
17	- Designing partition-tolerant systems with proper consistency guarantees
18	- Building resilient services with circuit breakers, bulkheads, retries
19	- Implementing service discovery and inter-service communication
20
21	## Core Concepts
22
23	### CAP Theorem Fundamentals
24
25	CAP Theorem: In a distributed system experiencing a network partition, choose between Consistency (C) or Availability (A). Partition tolerance (P) is mandatory.
26
27	```
28	Network partitions WILL occur → Always design for P
29
30	During partition:
31	├─ CP (Consistency + Partition Tolerance)
32	│ Use when: Financial transactions, inventory, seat booking
33	│ Trade-off: System unavailable during partition
34	│ Examples: HBase, MongoDB (default), etcd
35	│
36	└─ AP (Availability + Partition Tolerance)
37	Use when: Social media, caching, analytics, shopping carts
38	Trade-off: Stale reads possible, conflicts need resolution
39	Examples: Cassandra, DynamoDB, Riak
40	```
41
42	PACELC: Extends CAP to consider normal operations (no partition).
43	- If Partition: Choose Availability (A) or Consistency (C)
44	- Else (normal): Choose Latency (L) or Consistency (C)
45
46	### Consistency Models Spectrum
47
48	```
49	Strong Consistency ◄─────────────────────► Eventual Consistency
50	│ │ │
51	Linearizable Causal Consistency Convergent
52	(Slowest, (Middle Ground, (Fastest,
53	Most Consistent) Causally Ordered) Eventually Consistent)
54	```
55
56	Strong Consistency (Linearizability):
57	- All operations appear atomically in sequential order
58	- Reads always return most recent write
59	- Use for: Bank balances, inventory stock, seat booking
60	- Trade-off: Higher latency, reduced availability
61
62	Eventual Consistency:
63	- If no new updates, all replicas eventually converge
64	- Use for: Social feeds, product catalogs, user profiles, DNS
65	- Trade-off: Stale reads possible, conflict resolution needed
66
67	Causal Consistency:
68	- Causally related operations seen in same order by all nodes
69	- Use for: Chat apps, collaborative editing, comment threads
70	- Trade-off: More complex than eventual, requires causality tracking
71
72	Bounded Staleness:
73	- Staleness bounded by time or version count
74	- Use for: Real-time dashboards, leaderboards, monitoring
75	- Trade-off: Must monitor lag, more complex than eventual
76
77	### Replication Patterns
78
79	1. Leader-Follower (Single-Leader):
80	- All writes to leader, replicated to followers
81	- Followers handle reads (load distribution)
82	- Synchronous: Wait for follower ACK (strong consistency, higher latency)
83	- Asynchronous: Don't wait (eventual consistency, possible data loss)
84	- Use for: Most common pattern, strong consistency with sync replication
85
86	2. Multi-Leader:
87	- Multiple leaders accept writes in different datacenters
88	- Leaders replicate to each other
89	- Conflict resolution required: Last-Write-Wins, application merge, vector clocks
90	- Use for: Multi-datacenter, low write latency, geo-distributed users
91	- Trade-off: Conflict resolution complexity
92
93	3. Leaderless (Dynamo-style):
94	- No single leader, quorum-based reads/writes
95	- Quorum rule: W + R > N (W=write quorum, R=read quorum, N=replicas)
96	- Example: N=5, W=3, R=2 → Strong consistency (overlap guaranteed)
97	- Use for: Maximum availability, partition tolerance
98	- Trade-off: Complexity, read repair needed
99
100	### Partitioning Strategies
101
102	Hash Partitioning (Consistent Hashing):
103	- Key → Hash(Key) → Partition assignment
104	- Even distribution, minimal rebalancing when nodes added/removed
105	- Use for: Point queries by ID, even distribution critical
106	- Examples: Cassandra, DynamoDB, Redis Cluster
107
108	**Range Parti

People who liked this also viewed

6 picks

Type

designing-distributed-systems

78installs59forks

View on GitHub

How to install designing-distributed-systems?

ancoleman/ai-design-components/designing-distributed-systems

$npx -y skills add ancoleman/ai-design-components --skill designing-distributed-systems

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Designing Distributed Systems
2
3	Design scalable, reliable, and fault-tolerant distributed systems using proven patterns and consistency models.
4
5	## Purpose
6
7	Distributed systems are the foundation of modern cloud-native applications. Understanding fundamental trade-offs (CAP theorem, PACELC), consistency models, replication patterns, and resilience strategies is essential for building systems that scale globally while maintaining correctness and availability.
8
9	## When to Use This Skill
10
11	Apply when:
12	- Designing microservices architectures with multiple services
13	- Building systems that must scale across multiple datacenters or regions
14	- Choosing between consistency vs availability during network partitions
15	- Selecting replication strategies (single-leader, multi-leader, leaderless)
16	- Implementing distributed transactions (saga pattern, event sourcing, CQRS)
17	- Designing partition-tolerant systems with proper consistency guarantees
18	- Building resilient services with circuit breakers, bulkheads, retries
19	- Implementing service discovery and inter-service communication
20
21	## Core Concepts
22
23	### CAP Theorem Fundamentals
24
25	CAP Theorem: In a distributed system experiencing a network partition, choose between Consistency (C) or Availability (A). Partition tolerance (P) is mandatory.
26
27	```
28	Network partitions WILL occur → Always design for P
29
30	During partition:
31	├─ CP (Consistency + Partition Tolerance)
32	│ Use when: Financial transactions, inventory, seat booking
33	│ Trade-off: System unavailable during partition
34	│ Examples: HBase, MongoDB (default), etcd
35	│
36	└─ AP (Availability + Partition Tolerance)
37	Use when: Social media, caching, analytics, shopping carts
38	Trade-off: Stale reads possible, conflicts need resolution
39	Examples: Cassandra, DynamoDB, Riak
40	```
41
42	PACELC: Extends CAP to consider normal operations (no partition).
43	- If Partition: Choose Availability (A) or Consistency (C)
44	- Else (normal): Choose Latency (L) or Consistency (C)
45
46	### Consistency Models Spectrum
47
48	```
49	Strong Consistency ◄─────────────────────► Eventual Consistency
50	│ │ │
51	Linearizable Causal Consistency Convergent
52	(Slowest, (Middle Ground, (Fastest,
53	Most Consistent) Causally Ordered) Eventually Consistent)
54	```
55
56	Strong Consistency (Linearizability):
57	- All operations appear atomically in sequential order
58	- Reads always return most recent write
59	- Use for: Bank balances, inventory stock, seat booking
60	- Trade-off: Higher latency, reduced availability
61
62	Eventual Consistency:
63	- If no new updates, all replicas eventually converge
64	- Use for: Social feeds, product catalogs, user profiles, DNS
65	- Trade-off: Stale reads possible, conflict resolution needed
66
67	Causal Consistency:
68	- Causally related operations seen in same order by all nodes
69	- Use for: Chat apps, collaborative editing, comment threads
70	- Trade-off: More complex than eventual, requires causality tracking
71
72	Bounded Staleness:
73	- Staleness bounded by time or version count
74	- Use for: Real-time dashboards, leaderboards, monitoring
75	- Trade-off: Must monitor lag, more complex than eventual
76
77	### Replication Patterns
78
79	1. Leader-Follower (Single-Leader):
80	- All writes to leader, replicated to followers
81	- Followers handle reads (load distribution)
82	- Synchronous: Wait for follower ACK (strong consistency, higher latency)
83	- Asynchronous: Don't wait (eventual consistency, possible data loss)
84	- Use for: Most common pattern, strong consistency with sync replication
85
86	2. Multi-Leader:
87	- Multiple leaders accept writes in different datacenters
88	- Leaders replicate to each other
89	- Conflict resolution required: Last-Write-Wins, application merge, vector clocks
90	- Use for: Multi-datacenter, low write latency, geo-distributed users
91	- Trade-off: Conflict resolution complexity
92
93	3. Leaderless (Dynamo-style):
94	- No single leader, quorum-based reads/writes
95	- Quorum rule: W + R > N (W=write quorum, R=read quorum, N=replicas)
96	- Example: N=5, W=3, R=2 → Strong consistency (overlap guaranteed)
97	- Use for: Maximum availability, partition tolerance
98	- Trade-off: Complexity, read repair needed
99
100	### Partitioning Strategies
101
102	Hash Partitioning (Consistent Hashing):
103	- Key → Hash(Key) → Partition assignment
104	- Even distribution, minimal rebalancing when nodes added/removed
105	- Use for: Point queries by ID, even distribution critical
106	- Examples: Cassandra, DynamoDB, Redis Cluster
107
108	**Range Parti

People who liked this also viewed

6 picks

Type