Core Code
Core Code Modern Dev Handbook
SYSTEM-DESIGN Contents
Constraints & Core Metrics
What Is System Design (Production-First) Functional vs Non-Functional Requirements Constraints, Assumptions, and Design Inputs Latency vs Throughput Tail Latency (p95/p99) and Why It Dominates UX SLI, SLO, SLA: The Reliability Contract Capacity Estimation Basics Bottlenecks and Queues (Little's Law Intuition)
Scaling & Traffic Management
Vertical vs Horizontal Scaling Load Balancing Fundamentals Caching Strategies Overview Cache Invalidation and Consistency Rate Limiting at Scale Backpressure: Preventing Overload Timeouts and Retries (Safe Defaults) Graceful Degradation and Traffic Shedding
Data & Consistency
Database Scaling Basics Replication: Read Replicas and Failover Consistency Models (Strong vs Eventual) Sharding Basics Partitioning and Hotspot Avoidance Idempotency and Deduplication Eventual Consistency and UX Schema Evolution and Backward Compatibility
Reliability Patterns
Timeouts: Bounding Damage Retry Strategies (Jitter, Caps, Budgets) Circuit Breaker Bulkhead Pattern Fallbacks and Graceful Degradation Load Shedding and Admission Control Backups and Restore Strategy Disaster Recovery (RPO/RTO)
Observability & Control
Golden Signals: Latency, Traffic, Errors, Saturation Metrics: SLIs and SLO Targets Logging at Scale (Structure and Cost) Correlation IDs and Context Propagation Distributed Tracing Overview Alerting and Runbooks Capacity Planning and Saturation Postmortems and Continuous Improvement
Case Studies
Case Study: URL Shortener Case Study: File Upload and Serving Case Study: Notification System Case Study: Chat System Overview Case Study: Rate Limiter Service Case Study: Social Feed (Fan-out Trade-offs) Case Study: Search Autocomplete Case Study: Analytics Ingestion Pipeline
Distributed Systems Foundations
CAP Theorem Consensus Basics Leader Election Distributed Locking Clock Skew Split Brain Quorum Reads and Writes Eventual vs Strong Consistency (Practical)
Service Communication Patterns
Synchronous vs Asynchronous Request-Response Pattern Message Queues Pub/Sub Pattern Event-Driven Architecture Saga Pattern CQRS Overview Outbox Pattern API Gateway Pattern Backend For Frontend (BFF)
Data at Scale Advanced
Index Design Deep Dive Query Planning Multi-Region Databases Read-After-Write Guarantees Global Databases Data Locality Large Table Strategies Background Jobs Design
Multi-Region Architecture
Multi-Region Basics Active-Active Active-Passive Geo DNS Cross-Region Replication Global Latency Optimization Regional Failover
Cost-Aware System Design
Cost vs Performance Storage Cost Trade-offs Cache Cost Analysis Overprovisioning vs Risk Cloud Pricing Mental Model Right-Sizing Instances
Security Architecture
Zero Trust Service-to-Service Auth Secrets Management Encryption at Rest Encryption in Transit DDoS Protection Multi-Tenant Data Isolation
System Design Interview
Design Twitter Design YouTube Design Uber Design Payment System Design E-commerce Platform Design Distributed Cache

Consensus Basics

Learn how distributed nodes agree on state using consensus principles.
On this page

What Consensus Solves

Consensus is how a set of nodes agree on a single decision or ordered log of decisions, even when some nodes fail or messages are delayed. In production, consensus is the foundation for leader election, replicated state machines, and coordination services.

The Problem: Agreement Under Failure

In a single process, state is obvious. In distributed systems, state must be replicated. Replication introduces disagreement when nodes observe events in different orders or lose connectivity. Consensus creates a shared source of truth for critical coordination decisions.

Where You Encounter Consensus

  • Choosing a leader for a cluster
  • Maintaining a consistent configuration store
  • Coordinating membership changes
  • Serializing writes into an ordered log

Consensus Is Not a Database Feature

Consensus is a coordination mechanism. Many databases embed consensus-like protocols to replicate logs, but you should treat it as a distinct cost center: it adds latency, requires majority quorum, and demands careful operational discipline.

Majority Quorum Is the Usual Safety Rule

Most practical consensus systems rely on the idea that a majority of nodes overlap between decisions. This overlap prevents two different majorities from committing conflicting decisions at the same time.

Cluster size -> quorum (majority)
3 nodes -> 2
5 nodes -> 3
7 nodes -> 4

If you lose quorum, you can be available OR consistent, not both.

Latency and Availability Implications

Consensus typically requires multiple network round trips. That increases tail latency, especially cross-region. It also reduces availability: if you cannot reach a majority, you cannot safely commit new decisions.

Production Smells

  • Using consensus for high-volume data writes (expensive and slow)
  • Running even-sized clusters (no benefit, same quorum size as odd+1)
  • Cross-region consensus without strict latency budgeting
  • Assuming consensus eliminates all failures (it does not)

Production-First Takeaway

Consensus is for coordination, not bulk data. Use it to pick leaders and serialize critical decisions, accept the latency and quorum requirements, and design your system so loss of quorum is a controlled operational state.

Leader Election →