CAP Theorem

// CAP visualisation
//
//        Consistency (C)
//           /    \
//          /      \
//     CP systems   CA systems
//    (HBase,       (single-node
//     MongoDB,      RDBMS — not
//     etcd)         distributed)
//          \      /
//           \    /
//     Partition Tolerance (P)
//           /    \
//          /      \
//     AP systems
//    (Cassandra, DynamoDB,
//     CouchDB, Riak)
//          \
//      Availability (A)

// Network partitions are INEVITABLE in distributed systems
// → the real choice is C vs A during a partition.

// CP example — MongoDB with majority read concern
db.orders.find({ _id: "order-123" })
  .readConcern("majority")   // waits for majority of replicas to confirm
  .maxTimeMS(5000);           // times out (unavailable) if partition prevents majority

// AP example — Cassandra with ONE consistency level
SELECT * FROM orders WHERE id = 'order-123';
-- CONSISTENCY ONE: returns data from nearest replica
-- Fast + available, but might be stale during partition
-- After partition heals, read-repair + anti-entropy sync data

// DynamoDB — tunable per-request
// Eventually consistent read (AP): lower latency, might be stale
// Strongly consistent read (CP): higher latency, always fresh
const params = {
  TableName: 'Orders',
  Key: { id: { S: 'order-123' } },
  ConsistentRead: true  // CP mode
};

// PACELC examples:
//
// System        | Partition → | Else →
// ──────────────────────────────────────
// DynamoDB      |     PA      |   EL   (fast reads, eventual consistency)
// Cassandra     |     PA      |   EL   (tunable, defaults to eventual)
// MongoDB       |     PC      |   EC   (majority writes, consistent reads)
// HBase/ZooKeeper |   PC      |   EC   (strong consistency, higher latency)
// CockroachDB   |     PC      |   EC   (serializable by default)
// Cosmos DB     |  Tunable    | Tunable (5 consistency levels)