Consistency describes which values clients may observe and in what order. Strong consistency often means operations behave as though they occurred atomically in a single order that respects real-time constraints. Eventual consistency allows replicas to temporarily disagree but expects convergence when updates stop and replication succeeds.

Read-your-writes means a client sees its own successful updates. Monotonic reads means a client does not move backward to an older version. Causal consistency preserves cause-and-effect order. These weaker guarantees can improve availability or latency but require product-aware behavior.

A profile page may tolerate a brief stale follower count; a payment balance or inventory reservation may require stronger guarantees. Do not use “eventual consistency” as a vague excuse: define the maximum expected staleness, how clients behave, and how conflicts are resolved.

Replication copies data to multiple nodes for availability, read scaling, and disaster recovery. Synchronous replication waits for a defined acknowledgment condition before confirming a write; asynchronous replication acknowledges earlier but can lose recent acknowledged writes during some failovers.

A read replica can reduce load on a primary, but replica lag means a read immediately after a write may return old data. Route correctness-sensitive reads to the primary or use a mechanism that waits for a replica to reach a required version.

Failover includes detection, promotion, routing changes, and client reconnection. Detection that is too slow extends downtime; detection that is too aggressive risks unnecessary failover or split-brain. Test the entire recovery path and measure recovery time and possible data loss rather than relying on a diagram.

Sharding divides a dataset across partitions so storage and throughput can grow beyond one node. A partition key determines where data lives. A good key distributes traffic and storage while supporting common queries; a poor key creates hotspots or forces expensive scatter-gather queries.

Range partitioning supports range scans but can overload a current-time or monotonically increasing key range. Hash partitioning distributes keys more evenly but makes range queries harder. Composite keys can balance query needs and distribution.

Resharding changes partition ownership and requires data movement, routing updates, and careful handling of concurrent writes. Design for partition-key evolution and monitor skew. Averages hide hot partitions: one shard at 95% utilization can be the bottleneck while the cluster average appears comfortable.

CAP is about behavior during a network partition: a distributed data system cannot guarantee both linearizable consistency and successful responses for every request on both sides of a partition. It is not a claim that every database permanently chooses only two of three features under normal operation.

Availability in CAP has a precise meaning: each request to a non-failing node receives a response, though the response may not contain the latest data. Real systems also trade latency, durability, and consistency under normal conditions, so CAP alone is not a complete design method.

Quorum systems use replica acknowledgments. In a simplified replicated set of N nodes, read and write quorums R and W may overlap when R + W > N, helping ensure a read intersects a successful write. This arithmetic does not by itself guarantee linearizability; versions, concurrent writes, failure handling, and the database's protocol matter.