Architecting Distributed Consensus

Given a scenario (e.g., "3-node cluster needs to agree on leader" or "resolve conflicting writes from 5 replicas"), produce three deliverables:

1. Consensus Flow — sequence of steps nodes follow to reach agreement
2. Voting Logic — quorum rules, tie-breaking, vote weighting
3. Recovery Strategy — how the system handles node failure, network partition, split-brain

Progress:

• Identify participants (node count, roles: proposer/acceptor/learner or leader/follower)
• Determine consistency requirement (strong vs eventual) — this dictates quorum size
• Define the Consensus Flow (propose → vote → commit/abort)
• Define Voting Logic (quorum formula, majority/weighted/Byzantine tolerance)
• Define Recovery Strategy (timeout handling, re-election, partition healing, conflict resolution order)
• Output all three sections in structured format

Step details:

• Participants: odd number of nodes preferred (avoids ties). State total N and required quorum Q.
• Consistency requirement: strong consistency → majority quorum (Q = floor(N/2)+1); eventual consistency → allow last-write-wins or CRDT merge instead of full consensus.
• Consensus Flow: name the phases explicitly (e.g., Prepare → Promise → Accept → Accepted, or RequestVote → Grant → Commit).
• Voting Logic: specify exact quorum math, what breaks ties (highest term/timestamp/node ID), and whether votes are weighted.
• Recovery Strategy: cover three failure modes separately — node crash, network partition, message loss/timeout.

Example 1: Input: "5-node cluster, need leader election, strong consistency required."

Output:

Consensus Flow:
1. Candidate increments term, votes for self
2. Sends RequestVote(term, lastLogIndex) to all peers
3. Peers grant vote if term is newer AND candidate's log is at least as up-to-date
4. Candidate becomes leader upon receiving majority grants
5. Leader sends heartbeats to maintain authority

Voting Logic:
- Quorum Q = floor(5/2)+1 = 3
- Tie-break: higher term wins; if equal term, higher lastLogIndex wins
- One vote per node per term (no weighting)

Recovery Strategy:
- Node crash: remaining nodes continue if quorum (3) still reachable
- Network partition: minority partition (<3 nodes) cannot elect leader, stays read-only/unavailable
- Timeout/message loss: candidate uses randomized election timeout (150-300ms) to reduce split votes; retry with incremented term

Example 2: Input: "3 replicas received conflicting writes to the same key during a partition."

Output:

Consensus Flow:
1. On partition heal, replicas exchange write history (vector clocks or version vectors)
2. Detect conflicting concurrent writes (no causal order)
3. Apply resolution policy
4. Propagate resolved value to all replicas

Voting Logic:
- Not a quorum vote — conflict resolved via deterministic policy:
  a) Last-Write-Wins by timestamp, or
  b) Application-level merge (CRDT), or
  c) Manual/side-by-side conflict surfaced to client
- Default recommendation: LWW with timestamp + node-id tiebreak for determinism

Recovery Strategy:
- Partition heal: run anti-entropy sync (Merkle tree diff) to find divergent keys
- Conflicting writes: apply chosen resolution policy, log conflict for audit
- Prevent recurrence: consider switching to quorum writes (W+R > N) if conflicts are frequent