consistency-coordination

Name: consistency-coordination
Author: proyecto26

45installs1forks

How to install consistency-coordination?

proyecto26/system-design-skills/consistency-coordination

$npx -y skills add proyecto26/system-design-skills --skill consistency-coordination

Installs into the current project.

Summary

This skill should be used when the user asks about the "CAP theorem", "PACELC", a "consistency model", "eventual vs strong consistency", "read-your-writes", "causal consistency", "quorum" or "R+W>N", "consensus", "Raft / Paxos", "leader election", "consistent hashing", a "distrib

Files · 1

View on GitHub

SKILL.md

1	# Consistency & Coordination
2
3	Decide what a reader is guaranteed to see when data lives on more than one node,
4	and how independent nodes agree on a single answer. Get this wrong and the system
5	either serves stale or conflicting data silently, or stalls the moment a network
6	link drops — the most common and most punishing distributed-systems failure.
7
8	## When to reach for this
9	Any time state is replicated, sharded, or coordinated across nodes: choosing a
10	replication or quorum scheme, picking a consistency level, electing a leader,
11	spreading keys across an elastic fleet (consistent hashing), or committing a
12	change that spans services. Reach here the instant someone asks "what does a read
13	see right after a write?" or "what happens during a partition?"
14
15	## When NOT to
16	A single node with no replicas has nothing to coordinate — don't invoke quorums or
17	consensus for it (YAGNI). Most apps tolerate seconds of staleness; reaching for
18	strong consistency or distributed transactions when eventual consistency would do
19	buys latency and operational pain for a guarantee no requirement asked for. The
20	cheapest model that satisfies the invariant wins. Naming Raft or 2PC before a
21	correctness requirement forces it is a red flag.
22
23	## Clarify first
24	- What breaks if a read is stale? A wrong balance vs a slightly old like count
25	are different systems. (→ `requirements-scoping`.)
26	- Must a user see their own writes immediately? Read-your-writes is far cheaper
27	than global strong consistency.
28	- What is the blast radius of a partition or lost region? Drives the CAP/PACELC
29	choice. (GUIDE failure mode #1.)
30	- Write contention and conflict shape — single-writer per key, or concurrent
31	writers needing conflict resolution?
32	- Latency budget — synchronous coordination adds a round trip (or a
33	cross-region one); confirm the budget allows it. (→ `back-of-the-envelope`.)
34
35	## The options
36
37	Pick a consistency model (the guarantee a read gets):
38	- Strong / linearizable — every read sees the latest committed write. Use when
39	an invariant must hold globally (balances, inventory, uniqueness).
40	- Read-your-writes / monotonic — a session sees its own writes and never goes
41	backward. Use for profile edits, "post then see your post".
42	- Causal — reads respect cause→effect order (a reply never precedes its
43	parent). Use for comments, chat, collaborative edits.
44	- Eventual — replicas converge "soon"; reads may lag. Use for like counts,
45	feeds, caches — anything where staleness is cheap.
46
47	Pick how copies agree:
48	- Single-leader (primary) — one node orders all writes; followers replicate.
49	Use when a clear write owner is acceptable; the common default.
50	- Quorum (R + W > N) — read/write to a majority; tune R and W per workload.
51	Use for leaderless stores needing tunable consistency and availability.
52	- Consensus (Raft / Paxos) — a majority agrees on a replicated log, even across
53	failures. Use for the control plane: leader election, config, metadata, locks.
54
55	Coordinate a multi-key / multi-service change:
56	- Saga — a sequence of local transactions with compensating undos. Use across
57	services where a global lock is impossible; accepts eventual consistency.
58	- 2PC / distributed transaction — atomic all-or-nothing across nodes via a
59	coordinator. Use only when atomicity is mandatory and the cost is accepted.
60
61	Spread keys across nodes — consistent hashing (this skill owns it): map keys
62	and nodes onto a hash ring; a key belongs to the next node clockwise. Adding or
63	removing a node remaps only ~K/N keys instead of nearly all (as plain
64	`hash(key) % N` does), avoiding a remap storm. Virtual nodes even out load and tame
65	hotspots. It is the standard partitioning scheme for caches, leaderless stores, and
66	LB backends. Mechanics in `references/deep-dive.md`.
67
68	## Trade-offs
69
70	\| Option \| What it solves \| What it worsens \| Change it when \|
71	\|---\|---\|---\|---\|
72	\| Strong/linearizable \| Correctness; no stale reads \| Latency (a round trip / quorum); unavailable under partition (CP) \| Staleness becomes tolerable → relax to read-your-writes/eventual \|
73	\| Read-your-writes \| "See my own change" without global cost \| Other users still see stale; needs session/sticky routing \| A global invariant appears → go strong \|
74	\| Eventual \| Highest availability + lowest latency (AP) \| Stale and conflicting reads; needs confli

People who liked this also viewed

6 picks

Type

consistency-coordination

45installs1forks

View on GitHub

How to install consistency-coordination?

proyecto26/system-design-skills/consistency-coordination

$npx -y skills add proyecto26/system-design-skills --skill consistency-coordination

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Consistency & Coordination
2
3	Decide what a reader is guaranteed to see when data lives on more than one node,
4	and how independent nodes agree on a single answer. Get this wrong and the system
5	either serves stale or conflicting data silently, or stalls the moment a network
6	link drops — the most common and most punishing distributed-systems failure.
7
8	## When to reach for this
9	Any time state is replicated, sharded, or coordinated across nodes: choosing a
10	replication or quorum scheme, picking a consistency level, electing a leader,
11	spreading keys across an elastic fleet (consistent hashing), or committing a
12	change that spans services. Reach here the instant someone asks "what does a read
13	see right after a write?" or "what happens during a partition?"
14
15	## When NOT to
16	A single node with no replicas has nothing to coordinate — don't invoke quorums or
17	consensus for it (YAGNI). Most apps tolerate seconds of staleness; reaching for
18	strong consistency or distributed transactions when eventual consistency would do
19	buys latency and operational pain for a guarantee no requirement asked for. The
20	cheapest model that satisfies the invariant wins. Naming Raft or 2PC before a
21	correctness requirement forces it is a red flag.
22
23	## Clarify first
24	- What breaks if a read is stale? A wrong balance vs a slightly old like count
25	are different systems. (→ `requirements-scoping`.)
26	- Must a user see their own writes immediately? Read-your-writes is far cheaper
27	than global strong consistency.
28	- What is the blast radius of a partition or lost region? Drives the CAP/PACELC
29	choice. (GUIDE failure mode #1.)
30	- Write contention and conflict shape — single-writer per key, or concurrent
31	writers needing conflict resolution?
32	- Latency budget — synchronous coordination adds a round trip (or a
33	cross-region one); confirm the budget allows it. (→ `back-of-the-envelope`.)
34
35	## The options
36
37	Pick a consistency model (the guarantee a read gets):
38	- Strong / linearizable — every read sees the latest committed write. Use when
39	an invariant must hold globally (balances, inventory, uniqueness).
40	- Read-your-writes / monotonic — a session sees its own writes and never goes
41	backward. Use for profile edits, "post then see your post".
42	- Causal — reads respect cause→effect order (a reply never precedes its
43	parent). Use for comments, chat, collaborative edits.
44	- Eventual — replicas converge "soon"; reads may lag. Use for like counts,
45	feeds, caches — anything where staleness is cheap.
46
47	Pick how copies agree:
48	- Single-leader (primary) — one node orders all writes; followers replicate.
49	Use when a clear write owner is acceptable; the common default.
50	- Quorum (R + W > N) — read/write to a majority; tune R and W per workload.
51	Use for leaderless stores needing tunable consistency and availability.
52	- Consensus (Raft / Paxos) — a majority agrees on a replicated log, even across
53	failures. Use for the control plane: leader election, config, metadata, locks.
54
55	Coordinate a multi-key / multi-service change:
56	- Saga — a sequence of local transactions with compensating undos. Use across
57	services where a global lock is impossible; accepts eventual consistency.
58	- 2PC / distributed transaction — atomic all-or-nothing across nodes via a
59	coordinator. Use only when atomicity is mandatory and the cost is accepted.
60
61	Spread keys across nodes — consistent hashing (this skill owns it): map keys
62	and nodes onto a hash ring; a key belongs to the next node clockwise. Adding or
63	removing a node remaps only ~K/N keys instead of nearly all (as plain
64	`hash(key) % N` does), avoiding a remap storm. Virtual nodes even out load and tame
65	hotspots. It is the standard partitioning scheme for caches, leaderless stores, and
66	LB backends. Mechanics in `references/deep-dive.md`.
67
68	## Trade-offs
69
70	\| Option \| What it solves \| What it worsens \| Change it when \|
71	\|---\|---\|---\|---\|
72	\| Strong/linearizable \| Correctness; no stale reads \| Latency (a round trip / quorum); unavailable under partition (CP) \| Staleness becomes tolerable → relax to read-your-writes/eventual \|
73	\| Read-your-writes \| "See my own change" without global cost \| Other users still see stale; needs session/sticky routing \| A global invariant appears → go strong \|
74	\| Eventual \| Highest availability + lowest latency (AP) \| Stale and conflicting reads; needs confli

People who liked this also viewed

6 picks

Type