Understanding System Models and Properties

1. Understanding CAP Theorem

PropertyMeaningSacrifice Under Partition
Consistency (C)Every read sees the latest write (linearizable)
Availability (A)Every request gets a non-error response
Partition Tolerance (P)System continues despite network partitionsMandatory in real systems
CP SystemsHBase, MongoDB (default), etcd, ZooKeeper, SpannerReject writes on minority side
AP SystemsCassandra, DynamoDB, Riak, CouchbaseAccept writes; reconcile later
Note: CAP is asymptotic — in absence of partition, systems can be both C and A. Real choice is between C and A only when P occurs.

2. Understanding PACELC Theorem

ConditionChoiceExamples
P (partition)A vs CSame as CAP
E (else, normal ops)L (latency) vs C (consistency)
PA/ELAvailable + low latencyCassandra, DynamoDB, Riak
PC/ECAlways consistentHBase, BigTable, Spanner (mostly)
PA/ECAvailable on partition, consistent normallyMongoDB

3. Understanding ACID vs BASE Properties

ACID (Strong)

  • Atomicity: All-or-nothing
  • Consistency: Invariants preserved
  • Isolation: Concurrent txns appear serial
  • Durability: Committed survives crash
  • Examples: PostgreSQL, MySQL, Oracle

BASE (Relaxed)

  • Basically Available: Always responds
  • Soft state: May change without input
  • Eventual consistency: Converges over time
  • Examples: Cassandra, DynamoDB, Riak

4. Understanding Fault Models

ModelAssumptionTolerance Cost
Crash-StopFailed nodes halt foreverf+1 nodes for f failures
Crash-RecoveryNodes may recover with persistent state2f+1 (Paxos/Raft)
OmissionMessages may be droppedRetransmission protocols
ByzantineArbitrary/malicious behavior3f+1 (PBFT)

5. Understanding Timing Models

ModelBound AssumptionPracticality
SynchronousKnown bounds on delay & clock driftReal-time/embedded only
AsynchronousNo timing assumptionsFLP impossibility for consensus
Partial SynchronyBounds exist but unknown, eventually holdReal-world model (Raft, Paxos)
Note: FLP Impossibility — In a fully async system with even one crash failure, deterministic consensus is impossible. Real systems use timeouts (partial synchrony).

6. Understanding System Guarantees

GuaranteeMeaning
Safety"Bad things never happen" (e.g., no two leaders)
Liveness"Good things eventually happen" (e.g., progress)
At-most-onceMessage delivered 0 or 1 times
At-least-onceMessage delivered ≥ 1 time (duplicates possible)
Exactly-onceEffectively once via dedup + idempotency

7. Understanding Availability Metrics (SLA, SLO, SLI)

TermDefinitionExample
SLIService Level Indicator — measured metricp99 latency = 120ms
SLOService Level Objective — internal target99.9% requests < 200ms
SLAService Level Agreement — contractual + penalty99.95% uptime or refund
Error Budget1 − SLO; allowed failure quota0.1% = 43.2 min/month

8. Understanding Durability Guarantees

LevelMechanismRisk
Memory onlyRAMLost on crash
Single disk fsyncWAL + fsyncDisk failure
RAIDMultiple disksHost failure
Replicated (sync)Quorum writeRegion failure
Cross-regionGeo-replicationMulti-region outage
11 nines (S3)Erasure coding + multi-AZ~10⁻¹¹/yr loss

9. Understanding Failure Modes

ModeSymptomDetection Strategy
Fail-stopProcess exitsTCP RST, heartbeat loss
Fail-slow / grayDegraded throughput/latencySLI monitoring, outlier detection
Network partitionSubset unreachableQuorum loss, gossip view
Resource exhaustionOOM, FD limit, disk fullUSE metrics, alerts
Data corruptionChecksum mismatchCRC, Merkle trees
Configuration driftInconsistent behaviorAudit, IaC reconciliation

10. Understanding Performance Guarantees

MetricCommon Target
p50 latency10-50ms
p99 latency100-500ms
p999 latency< 1-2s
ThroughputRPS sustained at SLO
Saturation< 70% utilization for headroom