Imran M
@im18.bsky.social
Cleared all the drafts today from my blog. Actually another 60-80 remaining :(
September 23, 2026 at 8:10 PM
Cleared all the drafts today from my blog. Actually another 60-80 remaining :(
Distributed Tracing: Following One Request Across Many Services
What is distributed tracing: the span and trace model, context propagation across services and queues, OpenTelemetry tracing and vendor tools, and the sampling that makes it affordable; the pillar that answers "where did the time go?"
What is distributed tracing: the span and trace model, context propagation across services and queues, OpenTelemetry tracing and vendor tools, and the sampling that makes it affordable; the pillar that answers "where did the time go?"
Distributed Tracing: Following One Request Across Many Services
What is distributed tracing: the span and trace model, context propagation across services and queues, OpenTelemetry tracing and vendor tools, and the sampling that makes it affordable; the pillar that answers "where did the time go?"
imraan.in
September 23, 2026 at 6:58 PM
Distributed Tracing: Following One Request Across Many Services
What is distributed tracing: the span and trace model, context propagation across services and queues, OpenTelemetry tracing and vendor tools, and the sampling that makes it affordable; the pillar that answers "where did the time go?"
What is distributed tracing: the span and trace model, context propagation across services and queues, OpenTelemetry tracing and vendor tools, and the sampling that makes it affordable; the pillar that answers "where did the time go?"
Metrics: Golden Signals, RED, and USE
Metrics monitoring for a distributed fleet: time series metrics (counters, gauges, histograms) the four golden signals, RED vs USE and when each applies, and the budget-based alerting that keeps pages honest.
Metrics monitoring for a distributed fleet: time series metrics (counters, gauges, histograms) the four golden signals, RED vs USE and when each applies, and the budget-based alerting that keeps pages honest.
Metrics: Golden Signals, RED, and USE
Metrics monitoring for a distributed fleet: time series metrics (counters, gauges, histograms) the four golden signals, RED vs USE and when each applies, and the budget-based alerting that keeps pages honest.
imraan.in
September 23, 2026 at 6:57 PM
Metrics: Golden Signals, RED, and USE
Metrics monitoring for a distributed fleet: time series metrics (counters, gauges, histograms) the four golden signals, RED vs USE and when each applies, and the budget-based alerting that keeps pages honest.
Metrics monitoring for a distributed fleet: time series metrics (counters, gauges, histograms) the four golden signals, RED vs USE and when each applies, and the budget-based alerting that keeps pages honest.
Logging: Structured, Centralized, and Searchable
Structured logging, log levels, centralized logging, and log aggregation: how a distributed fleet turns scattered events into one searchable record; the pillar that answers "what exactly happened?"
Structured logging, log levels, centralized logging, and log aggregation: how a distributed fleet turns scattered events into one searchable record; the pillar that answers "what exactly happened?"
Logging: Structured, Centralized, and Searchable
Structured logging, log levels, centralized logging, and log aggregation: how a distributed fleet turns scattered events into one searchable record; the pillar that answers "what exactly happened?"
imraan.in
September 23, 2026 at 6:56 PM
Logging: Structured, Centralized, and Searchable
Structured logging, log levels, centralized logging, and log aggregation: how a distributed fleet turns scattered events into one searchable record; the pillar that answers "what exactly happened?"
Structured logging, log levels, centralized logging, and log aggregation: how a distributed fleet turns scattered events into one searchable record; the pillar that answers "what exactly happened?"
Monitoring and Observability: Knowing What Your System Is Doing
Observability vs monitoring, drawn honestly: what observability is as a property, the three pillars (logs, metrics, traces) the telemetry data pipeline that carries them, and the one table that says which pillar answers which question.
Observability vs monitoring, drawn honestly: what observability is as a property, the three pillars (logs, metrics, traces) the telemetry data pipeline that carries them, and the one table that says which pillar answers which question.
Monitoring and Observability: Knowing What Your System Is Doing
Observability vs monitoring, drawn honestly: what observability is as a property, the three pillars (logs, metrics, traces) the telemetry data pipeline that carries them, and the one table that says which pillar answers which question.
imraan.in
September 23, 2026 at 6:56 PM
Monitoring and Observability: Knowing What Your System Is Doing
Observability vs monitoring, drawn honestly: what observability is as a property, the three pillars (logs, metrics, traces) the telemetry data pipeline that carries them, and the one table that says which pillar answers which question.
Observability vs monitoring, drawn honestly: what observability is as a property, the three pillars (logs, metrics, traces) the telemetry data pipeline that carries them, and the one table that says which pillar answers which question.
Monolith vs Microservices: The Decision, Not the Fashion
Monolith vs microservices decided honestly: the side-by-side comparison on team shapes, scaling, and operational maturity, the modular monolith middle path, and when to use microservices because the trade offs say so, not the fashion.
Monolith vs microservices decided honestly: the side-by-side comparison on team shapes, scaling, and operational maturity, the modular monolith middle path, and when to use microservices because the trade offs say so, not the fashion.
Monolith vs Microservices: The Decision, Not the Fashion
Monolith vs microservices decided honestly: the side-by-side comparison on team shapes, scaling, and operational maturity, the modular monolith middle path, and when to use microservices because the trade offs say so, not the fashion.
imraan.in
September 23, 2026 at 6:55 PM
Monolith vs Microservices: The Decision, Not the Fashion
Monolith vs microservices decided honestly: the side-by-side comparison on team shapes, scaling, and operational maturity, the modular monolith middle path, and when to use microservices because the trade offs say so, not the fashion.
Monolith vs microservices decided honestly: the side-by-side comparison on team shapes, scaling, and operational maturity, the modular monolith middle path, and when to use microservices because the trade offs say so, not the fashion.
Kafka vs RabbitMQ: Choosing a Message Broker
Kafka vs RabbitMQ decided on model shape, not brand: the durable log versus classic routing, when to use kafka, where RabbitMQ's routing and per-message control wins, and the workloads that honestly run both.
Kafka vs RabbitMQ decided on model shape, not brand: the durable log versus classic routing, when to use kafka, where RabbitMQ's routing and per-message control wins, and the workloads that honestly run both.
Kafka vs RabbitMQ: Choosing a Message Broker
Kafka vs RabbitMQ decided on model shape, not brand: the durable log versus classic routing, when to use kafka, where RabbitMQ's routing and per-message control wins, and the workloads that honestly run both.
imraan.in
September 23, 2026 at 6:55 PM
Kafka vs RabbitMQ: Choosing a Message Broker
Kafka vs RabbitMQ decided on model shape, not brand: the durable log versus classic routing, when to use kafka, where RabbitMQ's routing and per-message control wins, and the workloads that honestly run both.
Kafka vs RabbitMQ decided on model shape, not brand: the durable log versus classic routing, when to use kafka, where RabbitMQ's routing and per-message control wins, and the workloads that honestly run both.
Circuit Breaker Pattern: States, Failing Fast, and Bulkheads
The circuit breaker pattern: the three circuit breaker states, failing fast with real fallbacks, and the bulkhead pattern that caps the blast radius, how a fleet survives a failing dependency.
The circuit breaker pattern: the three circuit breaker states, failing fast with real fallbacks, and the bulkhead pattern that caps the blast radius, how a fleet survives a failing dependency.
Circuit Breaker Pattern: States, Failing Fast, and Bulkheads
The circuit breaker pattern: the three circuit breaker states, failing fast with real fallbacks, and the bulkhead pattern that caps the blast radius, how a fleet survives a failing dependency.
imraan.in
September 23, 2026 at 6:53 PM
Circuit Breaker Pattern: States, Failing Fast, and Bulkheads
The circuit breaker pattern: the three circuit breaker states, failing fast with real fallbacks, and the bulkhead pattern that caps the blast radius, how a fleet survives a failing dependency.
The circuit breaker pattern: the three circuit breaker states, failing fast with real fallbacks, and the bulkhead pattern that caps the blast radius, how a fleet survives a failing dependency.
Event Driven Architecture: Pub/Sub, Event Sourcing, and Choreography
Event driven architecture: the pub/sub vs message queue comparison, event sourcing as the system of record, and choreography vs orchestration, how services coordinate without a conductor.
Event driven architecture: the pub/sub vs message queue comparison, event sourcing as the system of record, and choreography vs orchestration, how services coordinate without a conductor.
Event Driven Architecture: Pub/Sub, Event Sourcing, and Choreography
Event driven architecture: the pub/sub vs message queue comparison, event sourcing as the system of record, and choreography vs orchestration, how services coordinate without a conductor.
imraan.in
September 23, 2026 at 6:53 PM
Event Driven Architecture: Pub/Sub, Event Sourcing, and Choreography
Event driven architecture: the pub/sub vs message queue comparison, event sourcing as the system of record, and choreography vs orchestration, how services coordinate without a conductor.
Event driven architecture: the pub/sub vs message queue comparison, event sourcing as the system of record, and choreography vs orchestration, how services coordinate without a conductor.
Message Queues in System Design: Delivery Guarantees and Dead Letters
Message queues in system design: the at-least-once vs exactly-once delivery comparison, message ordering, and the dead letter queue that keeps poison messages from jamming the pipeline.
Message queues in system design: the at-least-once vs exactly-once delivery comparison, message ordering, and the dead letter queue that keeps poison messages from jamming the pipeline.
Message Queues in System Design: Delivery Guarantees and Dead Letters
Message queues in system design: the at-least-once vs exactly-once delivery comparison, message ordering, and the dead letter queue that keeps poison messages from jamming the pipeline.
imraan.in
September 23, 2026 at 6:51 PM
Message Queues in System Design: Delivery Guarantees and Dead Letters
Message queues in system design: the at-least-once vs exactly-once delivery comparison, message ordering, and the dead letter queue that keeps poison messages from jamming the pipeline.
Message queues in system design: the at-least-once vs exactly-once delivery comparison, message ordering, and the dead letter queue that keeps poison messages from jamming the pipeline.
Microservices Architecture: Trade-offs, Boundaries, and When Not to Use Them
Microservices architecture explained: service boundaries and bounded contexts, the microservices trade-offs in both directions, and honest guidance on when not to use microservices.
Microservices architecture explained: service boundaries and bounded contexts, the microservices trade-offs in both directions, and honest guidance on when not to use microservices.
Microservices Architecture: Trade-offs, Boundaries, and When Not to Use Them
Microservices architecture explained: service boundaries and bounded contexts, the microservices trade-offs in both directions, and honest guidance on when not to use microservices.
imraan.in
September 23, 2026 at 6:50 PM
Microservices Architecture: Trade-offs, Boundaries, and When Not to Use Them
Microservices architecture explained: service boundaries and bounded contexts, the microservices trade-offs in both directions, and honest guidance on when not to use microservices.
Microservices architecture explained: service boundaries and bounded contexts, the microservices trade-offs in both directions, and honest guidance on when not to use microservices.
Blue-Green vs Canary Deployment: Shipping Without Downtime
Blue green vs canary deployment decided: zero downtime deployment mechanics, the canary release strategy and its observation ramp, deployment rollback in both worlds, rolling deployment as the third option, and the decision table for which…
Blue green vs canary deployment decided: zero downtime deployment mechanics, the canary release strategy and its observation ramp, deployment rollback in both worlds, rolling deployment as the third option, and the decision table for which…
Blue-Green vs Canary Deployment: Shipping Without Downtime
Blue green vs canary deployment decided: zero downtime deployment mechanics, the canary release strategy and its observation ramp, deployment rollback in both worlds, rolling deployment as the third option, and the decision table for which change deserves which.
imraan.in
September 23, 2026 at 6:49 PM
Blue-Green vs Canary Deployment: Shipping Without Downtime
Blue green vs canary deployment decided: zero downtime deployment mechanics, the canary release strategy and its observation ramp, deployment rollback in both worlds, rolling deployment as the third option, and the decision table for which…
Blue green vs canary deployment decided: zero downtime deployment mechanics, the canary release strategy and its observation ramp, deployment rollback in both worlds, rolling deployment as the third option, and the decision table for which…
Retry with Backoff and Jitter: Retrying Without Triggering Retry Storms
Retry with exponential backoff explained: backoff and jitter pacing, the retry storm math, retry budgets, what is safe to retry, and the circuit breaker vs retry comparison, settled with the decision table the breaker article…
Retry with exponential backoff explained: backoff and jitter pacing, the retry storm math, retry budgets, what is safe to retry, and the circuit breaker vs retry comparison, settled with the decision table the breaker article…
Retry with Backoff and Jitter: Retrying Without Triggering Retry Storms
Retry with exponential backoff explained: backoff and jitter pacing, the retry storm math, retry budgets, what is safe to retry, and the circuit breaker vs retry comparison, settled with the decision table the breaker article deferred.
imraan.in
September 23, 2026 at 6:49 PM
Retry with Backoff and Jitter: Retrying Without Triggering Retry Storms
Retry with exponential backoff explained: backoff and jitter pacing, the retry storm math, retry budgets, what is safe to retry, and the circuit breaker vs retry comparison, settled with the decision table the breaker article…
Retry with exponential backoff explained: backoff and jitter pacing, the retry storm math, retry budgets, what is safe to retry, and the circuit breaker vs retry comparison, settled with the decision table the breaker article…
Disaster Recovery: RTO, RPO, and Getting Back Online
Disaster recovery explained: RTO and RPO as the two numbers that size the plan, the disaster recovery strategies ladder from backups to warm standby, multi region failover mechanics, and the drill that turns a plan into a capability.
Disaster recovery explained: RTO and RPO as the two numbers that size the plan, the disaster recovery strategies ladder from backups to warm standby, multi region failover mechanics, and the drill that turns a plan into a capability.
Disaster Recovery: RTO, RPO, and Getting Back Online
Disaster recovery explained: RTO and RPO as the two numbers that size the plan, the disaster recovery strategies ladder from backups to warm standby, multi region failover mechanics, and the drill that turns a plan into a capability.
imraan.in
September 23, 2026 at 5:52 PM
Disaster Recovery: RTO, RPO, and Getting Back Online
Disaster recovery explained: RTO and RPO as the two numbers that size the plan, the disaster recovery strategies ladder from backups to warm standby, multi region failover mechanics, and the drill that turns a plan into a capability.
Disaster recovery explained: RTO and RPO as the two numbers that size the plan, the disaster recovery strategies ladder from backups to warm standby, multi region failover mechanics, and the drill that turns a plan into a capability.
High Availability: Designing Away Single Points of Failure
High availability explained: the single point of failure hunt, n+1 redundancy sizing, failover design that does not become its own incident, and the availability budget the nines actually describe.
High availability explained: the single point of failure hunt, n+1 redundancy sizing, failover design that does not become its own incident, and the availability budget the nines actually describe.
High Availability: Designing Away Single Points of Failure
High availability explained: the single point of failure hunt, n+1 redundancy sizing, failover design that does not become its own incident, and the availability budget the nines actually describe.
imraan.in
September 23, 2026 at 5:49 PM
High Availability: Designing Away Single Points of Failure
High availability explained: the single point of failure hunt, n+1 redundancy sizing, failover design that does not become its own incident, and the availability budget the nines actually describe.
High availability explained: the single point of failure hunt, n+1 redundancy sizing, failover design that does not become its own incident, and the availability budget the nines actually describe.
Backpressure: Managing Load You Cannot Process
Backpressure explained: the flow-control signal that travels from a slow consumer back to its producers; bounded queues where the signal is born, flow control from TCP windows to message prefetch, queue-native pacing, and why sustained lag is a…
Backpressure explained: the flow-control signal that travels from a slow consumer back to its producers; bounded queues where the signal is born, flow control from TCP windows to message prefetch, queue-native pacing, and why sustained lag is a…
Backpressure: Managing Load You Cannot Process
Backpressure explained: the flow-control signal that travels from a slow consumer back to its producers; bounded queues where the signal is born, flow control from TCP windows to message prefetch, queue-native pacing, and why sustained lag is a capacity problem.
imraan.in
September 23, 2026 at 5:47 PM
Backpressure: Managing Load You Cannot Process
Backpressure explained: the flow-control signal that travels from a slow consumer back to its producers; bounded queues where the signal is born, flow control from TCP windows to message prefetch, queue-native pacing, and why sustained lag is a…
Backpressure explained: the flow-control signal that travels from a slow consumer back to its producers; bounded queues where the signal is born, flow control from TCP windows to message prefetch, queue-native pacing, and why sustained lag is a…
Load Shedding: Dropping Traffic to Stay Alive
Load shedding explained: overload survival by dropping work deliberately: graceful degradation ladders chosen in advance, server overload protection signals and priority lanes, which requests to shed, and how it composes with rate limiting, circuit…
Load shedding explained: overload survival by dropping work deliberately: graceful degradation ladders chosen in advance, server overload protection signals and priority lanes, which requests to shed, and how it composes with rate limiting, circuit…
Load Shedding: Dropping Traffic to Stay Alive
Load shedding explained: overload survival by dropping work deliberately: graceful degradation ladders chosen in advance, server overload protection signals and priority lanes, which requests to shed, and how it composes with rate limiting, circuit breaking, and backpressure.
imraan.in
September 23, 2026 at 5:45 PM
Load Shedding: Dropping Traffic to Stay Alive
Load shedding explained: overload survival by dropping work deliberately: graceful degradation ladders chosen in advance, server overload protection signals and priority lanes, which requests to shed, and how it composes with rate limiting, circuit…
Load shedding explained: overload survival by dropping work deliberately: graceful degradation ladders chosen in advance, server overload protection signals and priority lanes, which requests to shed, and how it composes with rate limiting, circuit…
Idempotency: Designing Operations That Survive Retries
Idempotency explained: operations that survive retries and duplicates, the idempotency key from client to dedup table, idempotent API design for POST-heavy services, and why at-least-once delivery makes it the reliability base layer.
Idempotency explained: operations that survive retries and duplicates, the idempotency key from client to dedup table, idempotent API design for POST-heavy services, and why at-least-once delivery makes it the reliability base layer.
Idempotency: Designing Operations That Survive Retries
Idempotency explained: operations that survive retries and duplicates, the idempotency key from client to dedup table, idempotent API design for POST-heavy services, and why at-least-once delivery makes it the reliability base layer.
imraan.in
September 23, 2026 at 5:44 PM
Idempotency: Designing Operations That Survive Retries
Idempotency explained: operations that survive retries and duplicates, the idempotency key from client to dedup table, idempotent API design for POST-heavy services, and why at-least-once delivery makes it the reliability base layer.
Idempotency explained: operations that survive retries and duplicates, the idempotency key from client to dedup table, idempotent API design for POST-heavy services, and why at-least-once delivery makes it the reliability base layer.
The Saga Pattern: Distributed Transactions Without Two-Phase Commit
The saga pattern explained: long-lived business transactions as local steps with compensating transactions, orchestration vs choreography, the transactional outbox that fixes the dual write, and the 2pc vs saga decision.
The saga pattern explained: long-lived business transactions as local steps with compensating transactions, orchestration vs choreography, the transactional outbox that fixes the dual write, and the 2pc vs saga decision.
The Saga Pattern: Distributed Transactions Without Two-Phase Commit
The saga pattern explained: long-lived business transactions as local steps with compensating transactions, orchestration vs choreography, the transactional outbox that fixes the dual write, and the 2pc vs saga decision.
imraan.in
September 23, 2026 at 5:42 PM
The Saga Pattern: Distributed Transactions Without Two-Phase Commit
The saga pattern explained: long-lived business transactions as local steps with compensating transactions, orchestration vs choreography, the transactional outbox that fixes the dual write, and the 2pc vs saga decision.
The saga pattern explained: long-lived business transactions as local steps with compensating transactions, orchestration vs choreography, the transactional outbox that fixes the dual write, and the 2pc vs saga decision.
Distributed Locks: Mutual Exclusion Across Machines
Distributed locks explained: leases and TTLs as mutual exclusion across machines; the Redis distributed lock and its failover caveat, the Redlock debate, fencing tokens as the defense that works when the lease fails, and honest lock expiration…
Distributed locks explained: leases and TTLs as mutual exclusion across machines; the Redis distributed lock and its failover caveat, the Redlock debate, fencing tokens as the defense that works when the lease fails, and honest lock expiration…
Distributed Locks: Mutual Exclusion Across Machines
Distributed locks explained: leases and TTLs as mutual exclusion across machines; the Redis distributed lock and its failover caveat, the Redlock debate, fencing tokens as the defense that works when the lease fails, and honest lock expiration practice.
imraan.in
September 23, 2026 at 5:39 PM
Distributed Locks: Mutual Exclusion Across Machines
Distributed locks explained: leases and TTLs as mutual exclusion across machines; the Redis distributed lock and its failover caveat, the Redlock debate, fencing tokens as the defense that works when the lease fails, and honest lock expiration…
Distributed locks explained: leases and TTLs as mutual exclusion across machines; the Redis distributed lock and its failover caveat, the Redlock debate, fencing tokens as the defense that works when the lease fails, and honest lock expiration…
Fault-Tolerant Systems: Redundancy, Failover, and Failure Detection
Fault tolerant system design: failure models from crash to byzantine, redundancy and the N+1 arithmetic, the failover playbook, and failure detection: heartbeats, timeouts, and phi accrual.
Fault tolerant system design: failure models from crash to byzantine, redundancy and the N+1 arithmetic, the failover playbook, and failure detection: heartbeats, timeouts, and phi accrual.
Fault-Tolerant Systems: Redundancy, Failover, and Failure Detection
Fault tolerant system design: failure models from crash to byzantine, redundancy and the N+1 arithmetic, the failover playbook, and failure detection: heartbeats, timeouts, and phi accrual.
imraan.in
September 23, 2026 at 5:37 PM
Fault-Tolerant Systems: Redundancy, Failover, and Failure Detection
Fault tolerant system design: failure models from crash to byzantine, redundancy and the N+1 arithmetic, the failover playbook, and failure detection: heartbeats, timeouts, and phi accrual.
Fault tolerant system design: failure models from crash to byzantine, redundancy and the N+1 arithmetic, the failover playbook, and failure detection: heartbeats, timeouts, and phi accrual.
Distributed Transactions: Two-Phase Commit and Its Alternatives
Distributed transactions explained: two-phase commit step by step, the 2pc coordinator failure that leaves participants in doubt, consensus-backed coordinators, distributed transaction examples from XA to Spanner and CockroachDB, and…
Distributed transactions explained: two-phase commit step by step, the 2pc coordinator failure that leaves participants in doubt, consensus-backed coordinators, distributed transaction examples from XA to Spanner and CockroachDB, and…
Distributed Transactions: Two-Phase Commit and Its Alternatives
Distributed transactions explained: two-phase commit step by step, the 2pc coordinator failure that leaves participants in doubt, consensus-backed coordinators, distributed transaction examples from XA to Spanner and CockroachDB, and when to pick something else.
imraan.in
September 23, 2026 at 5:35 PM
Distributed Transactions: Two-Phase Commit and Its Alternatives
Distributed transactions explained: two-phase commit step by step, the 2pc coordinator failure that leaves participants in doubt, consensus-backed coordinators, distributed transaction examples from XA to Spanner and CockroachDB, and…
Distributed transactions explained: two-phase commit step by step, the 2pc coordinator failure that leaves participants in doubt, consensus-backed coordinators, distributed transaction examples from XA to Spanner and CockroachDB, and…
Leader Election in Distributed Systems: Methods and Split-Brain Risk
Leader election in distributed systems explained: leader election algorithms from the bully algorithm to quorum voting, zookeeper leader election with ephemeral znodes, leases and fencing, and how real systems keep split brain…
Leader election in distributed systems explained: leader election algorithms from the bully algorithm to quorum voting, zookeeper leader election with ephemeral znodes, leases and fencing, and how real systems keep split brain…
Leader Election in Distributed Systems: Methods and Split-Brain Risk
Leader election in distributed systems explained: leader election algorithms from the bully algorithm to quorum voting, zookeeper leader election with ephemeral znodes, leases and fencing, and how real systems keep split brain out of production.
imraan.in
September 23, 2026 at 5:33 PM
Leader Election in Distributed Systems: Methods and Split-Brain Risk
Leader election in distributed systems explained: leader election algorithms from the bully algorithm to quorum voting, zookeeper leader election with ephemeral znodes, leases and fencing, and how real systems keep split brain…
Leader election in distributed systems explained: leader election algorithms from the bully algorithm to quorum voting, zookeeper leader election with ephemeral znodes, leases and fencing, and how real systems keep split brain…
Paxos Explained: The Algorithm Behind Most Consensus Systems
The Paxos algorithm explained: the paxos roles (proposers, acceptors, and learners) how prepare and accept ballots run, the safety argument that makes Paxos made simple, and Multi-Paxos, the production form behind Chubby and Spanner.
The Paxos algorithm explained: the paxos roles (proposers, acceptors, and learners) how prepare and accept ballots run, the safety argument that makes Paxos made simple, and Multi-Paxos, the production form behind Chubby and Spanner.
Paxos Explained: The Algorithm Behind Most Consensus Systems
The Paxos algorithm explained: the paxos roles (proposers, acceptors, and learners) how prepare and accept ballots run, the safety argument that makes Paxos made simple, and Multi-Paxos, the production form behind Chubby and Spanner.
imraan.in
September 23, 2026 at 5:31 PM
Paxos Explained: The Algorithm Behind Most Consensus Systems
The Paxos algorithm explained: the paxos roles (proposers, acceptors, and learners) how prepare and accept ballots run, the safety argument that makes Paxos made simple, and Multi-Paxos, the production form behind Chubby and Spanner.
The Paxos algorithm explained: the paxos roles (proposers, acceptors, and learners) how prepare and accept ballots run, the safety argument that makes Paxos made simple, and Multi-Paxos, the production form behind Chubby and Spanner.
Raft Explained: Leader Election, Log Replication, and Safety
The Raft consensus algorithm explained: raft leader election with randomized timeouts, raft log replication through a strong leader, and the raft safety properties that keep etcd, Consul, and CockroachDB consistent.
The Raft consensus algorithm explained: raft leader election with randomized timeouts, raft log replication through a strong leader, and the raft safety properties that keep etcd, Consul, and CockroachDB consistent.
Raft Explained: Leader Election, Log Replication, and Safety
The Raft consensus algorithm explained: raft leader election with randomized timeouts, raft log replication through a strong leader, and the raft safety properties that keep etcd, Consul, and CockroachDB consistent.
imraan.in
September 23, 2026 at 5:29 PM
Raft Explained: Leader Election, Log Replication, and Safety
The Raft consensus algorithm explained: raft leader election with randomized timeouts, raft log replication through a strong leader, and the raft safety properties that keep etcd, Consul, and CockroachDB consistent.
The Raft consensus algorithm explained: raft leader election with randomized timeouts, raft log replication through a strong leader, and the raft safety properties that keep etcd, Consul, and CockroachDB consistent.