principle-distributed-systemslisted

# Distributed Systems Multi-node systems fail partially and non-deterministically. Every design decision spans a space of consistency, availability, and latency trade-offs — name them explicitly. ## CAP and PACELC **CAP**: under a network **P**artition, choose **C**onsistency or **A**vailability — you cannot guarantee both. **PACELC** extends this to normal operation: even without a partition, every request trades **L**atency for **C**onsistency. Always name both axes: "This is AP/EL — available under partition, latency-favoured otherwise." Common placements: Cassandra (AP/EL), HBase (CP/EC), Spanner (CP/EC via TrueTime), DynamoDB (AP/EL by default, tunable). ## Consistency Models Ordered strongest → weakest: | Model | Promise | |-------|---------| | **Linearizable** | Reads always see the most recent committed write; operations appear atomic. Requires consensus. | | **Sequential** | All nodes observe operations in the same order, not necessarily wall-clock order. | | **Causal** | Causally related writes are observed in order; concurrent writes may diverge. | | **Read-your-writes** | A client always reads its own most recent write (single-session). | | **Monotonic reads** | A client never reads a value older than one it already read. | | **Eventual** | All replicas converge given sufficient time and no new writes. | Choose the weakest model that satisfies correctness. Most user-facing apps need only read-your-writes + monotonic reads; linearizability is expensive. #