Consistency Level

Also known as linearizability, this is the strictest level. A write operation must be acknowledged by all replicas in the quorum before it is confirmed to the client. Subsequent reads are guaranteed to return the most recent write. This provides the highest data accuracy but incurs the highest latency, as the system must wait for the slowest node. It is critical for financial or transactional systems where data integrity is paramount, but it can reduce availability during network partitions.

The most permissive level, favoring availability and low latency over immediate accuracy. A write is confirmed once it reaches the primary node. Replicas are updated asynchronously. Reads may temporarily return stale data until all replicas converge. This model is foundational to AP (Available, Partition-tolerant) systems like DNS or caching layers. It's suitable for high-throughput, non-critical data where temporary inconsistency is acceptable, such as social media feeds or product recommendation scores.

A pragmatic middle ground that guarantees reads are no more than a specified time period (e.g., 5 seconds) or a certain number of versions behind the latest write. It provides a quantifiable upper bound on data freshness. This is implemented using mechanisms like version vectors or hybrid logical clocks. It's ideal for collaborative applications, real-time dashboards, or search indexes where users can tolerate slight delays but require data to be reasonably up-to-date.

Guarantees that a single client session will observe its own writes. If a client writes data, their subsequent reads (within the same session) will reflect that write, even if other clients see stale data. This is often implemented using a session token that routes requests to a specific replica. It prevents confusing user experiences in interactive applications—like a user seeing their own comment immediately after posting it—while allowing more flexibility globally. It's a common model for web applications.

A specific guarantee that a process that performs a write will always see that write in its subsequent read operations. It is weaker than strong consistency but stronger than eventual consistency for the writing client. This is a subset of session consistency but does not necessarily maintain guarantees across different sessions from the same user. It's a fundamental expectation for most interactive systems and is often the minimum viable consistency level for user-facing data stores.

A configurable and widely used model where operations must receive acknowledgments from a majority (quorum) of replicas. For a cluster with N replicas, a write quorum W and a read quorum R are configured such that W + R > N. This ensures that read and write sets always overlap, guaranteeing that reads see the latest written data. By tuning W and R, administrators can bias the system towards faster reads or faster writes. This is the core of the PACELC theorem trade-offs in systems like Apache Cassandra and many vector databases.

A persistent, append-only log where all data modifications (writes, updates, deletes) are recorded before they are applied to the main vector index. This is the primary mechanism for ensuring durability (the 'D' in ACID) and enabling crash recovery. Even with a weak Consistency Level, the WAL ensures no committed write is lost if a node crashes. It is also essential for Point-in-Time Recovery (PITR).

A stability pattern for microservices that protects a system from cascading failures. In the context of a vector database client, a circuit breaker can monitor failures when communicating with database nodes (e.g., timeouts due to a node struggling with a strong Consistency Level requirement). After a threshold of failures, it 'opens' and stops sending requests for a period, allowing the node to recover. This pattern helps maintain overall system stability when database operations are slow or failing.