consensus-algorithms

Understand and apply distributed consensus algorithms for leader election, distributed locks, and consistent state. Outputs algorithm selection guide, Raft/Paxos explanation, implementation patterns, and failure scenario analysis.

Ir a la instalación

Repositorio: kalilurrahman/kr-claudiator-skills
Última actividad en el origen: 29 de marzo de 2026 a las 13:04
Idioma detectado de SKILL.md: inglés
Estrellas: 1
Forks: 0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.

npx skills add https://github.com/kalilurrahman/kr-claudiator-skills --skill consensus-algorithms

El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.

¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

Volver a la búsqueda Volver a la instalación

Consensus Algorithms

Consensus algorithms allow distributed nodes to agree on a single value even when some nodes fail. They underpin leader election, distributed locks, configuration management, and any system requiring strong consistency across replicas. Understanding consensus is essential for understanding Kubernetes, etcd, ZooKeeper, and Kafka.

The Consensus Problem

CHALLENGE: N nodes must agree on a value Any node can fail (crash or network partition) No shared memory; only message passing SAFETY requirements (what must never happen): Only a single value is decided A decided value was proposed by some node LIVENESS requirement (what must eventually happen): Some value is eventually decided (Not guaranteed during partition — see CAP theorem) CAP Theorem: Consistency (linearisability) + Availability + Partition Tolerance Choose 2. Consensus algorithms choose CP — consistency over availability.

Raft (Most Understandable)

RAFT ROLES: Leader: Receives writes; replicates to followers Follower: Passively replicate from leader Candidate: Seeking election; in between leader terms LEADER ELECTION: 1. All nodes start as followers with random election timeout (150-300ms) 2. If no heartbeat received before timeout → become Candidate 3. Increment term; vote for self; request votes from peers 4. Win majority → become Leader for this term 5. Send heartbeats to prevent new elections LOG REPLICATION: 1. Leader receives write; appends to its log 2. Leader sends AppendEntries to all followers 3. Followers append to their log; acknowledge 4. When majority acknowledge → entry is committed 5. Leader notifies followers of commit; they apply to state machine KEY PROPERTIES: - Leader has all committed entries (election guarantee) - Committed entries never overwritten - At most one leader per term

Consensus Algorithms

The Consensus Problem

Raft (Most Understandable)

import etcd3 import time import threading # etcd uses Raft internally; provides distributed KV with watches class DistributedLock: """Leader election / mutual exclusion using etcd leases.""" def __init__(self, etcd_endpoints: list[str], lock_name: str, ttl: int = 30): self.client = etcd3.client(host=etcd_endpoints[0].split(":")[0], port=int(etcd_endpoints[0].split(":")[1])) self.lock_name = f"/locks/{lock_name}" self.ttl = ttl self._lease = None self._acquired = False self._keepalive_thread = None def acquire(self, timeout: float = None) -> bool: """Try to acquire the lock. Returns True if acquired.""" deadline = time.time() + timeout if timeout else None while True: # Create a lease (auto-expires if we crash) self._lease = self.client.lease(self.ttl) lease_id = self._lease.id # Try to atomically create the lock key with our lease success, _ = self.client.transaction( compare=[self.client.transactions.version(self.lock_name) == 0], success=[self.client.transactions.put(self.lock_name, "locked", lease=self._lease)], failure=[], ) if success: self._acquired = True # Keep lease alive self._keepalive_thread = threading.Thread( target=self._keepalive, daemon=True ) self._keepalive_thread.start() return True if deadline and time.time() >= deadline: self._lease.revoke() return False time.sleep(0.1) def _keepalive(self): """Refresh lease to prevent expiry while we hold the lock.""" for _ in self.client.refresh_lease(self._lease): if not self._acquired: break def release(self): """Release the lock by revoking the lease.""" self._acquired = False if self._lease: self._lease.revoke() def __enter__(self): if not self.acquire(timeout=10): raise TimeoutError("Could not acquire distributed lock") return self def __exit__(self, *args): self.release() # Usage with DistributedLock(["etcd:2379"], "payment-processor", ttl=30) as lock: # Only one instance runs this at a time process_pending_payments()

name	consensus-algorithms
description	Understand and apply distributed consensus algorithms for leader election, distributed locks, and consistent state. Outputs algorithm selection guide, Raft/Paxos explanation, implementation patterns, and failure scenario analysis.
argument-hint	["cluster size","consistency requirements","network characteristics","failure tolerance"]
allowed-tools	Read, Write

name	consensus-algorithms
description	Understand and apply distributed consensus algorithms for leader election, distributed locks, and consistent state. Outputs algorithm selection guide, Raft/Paxos explanation, implementation patterns, and failure scenario analysis.
argument-hint	["cluster size","consistency requirements","network characteristics","failure tolerance"]
allowed-tools	Read, Write

Algorithm	Understandability	Performance	Flexibility	Use Case
Raft	High	Good	Moderate	etcd, CockroachDB, TiDB
Paxos	Low	Good	High	Google Chubby, Spanner
Zab (ZooKeeper)	Medium	Good	Low	Kafka, Hadoop coordination
PBFT	Very Low	Poor	High	Byzantine fault tolerance
Viewstamped Replication	Medium	Good	Moderate	Research, some databases

Anti-Pattern	Problem	Fix
Using consensus for high-throughput writes	Consensus adds latency; not for every write	Consensus for coordination; eventual consistency for data
Single etcd/ZooKeeper node	Defeats the purpose — no fault tolerance	Minimum 3 nodes (tolerates 1 failure); 5 for 2-failure tolerance
Ignoring network partitions	Leader may not know it lost leadership	Lease-based approach; leader steps down if lease expires
Rolling your own consensus	Extremely hard to get right	Use etcd, ZooKeeper, or Consul
Consensus for everything	Over-engineered; slow	Consensus only for coordination; not for all state

consensus-algorithms

Opciones de instalación

Revisa los archivos de origen