Strong Consistency

A write operation is only acknowledged to the client as successful after the data has been durably persisted to the primary node and all designated replica nodes. This ensures all copies are updated before any subsequent read can proceed, eliminating the risk of reading stale data. The trade-off is increased write latency, as the operation must wait for the slowest replica to confirm.

• Primary Use: Critical for financial transactions, configuration management, and any system where immediate, uniform data visibility is mandatory.
• Contrast with: Asynchronous replication, which acknowledges writes faster but risks temporary inconsistency.

Consistency is enforced by requiring a quorum, or majority, of nodes to participate in each operation. For a cluster with a replication factor of N, common quorum rules are:

• Write Quorum (W): Must write to W > N/2 nodes.
• Read Quorum (R): Must read from R > N/2 nodes.
• Rule: W + R > N.

This mathematical guarantee ensures that the read and write sets of nodes always overlap, guaranteeing the read will see at least one node with the latest written data. It provides fault tolerance while maintaining consistency, as the system can tolerate the failure of some nodes (up to N - W or N - R).

A single elected leader node coordinates all write operations. Clients send writes only to the leader. The leader replicates the write to a quorum of follower nodes using a replicated log (like a Write-Ahead Log). The write is only committed and executed once a majority of nodes have durably stored it. The leader then informs the client of success and ensures followers apply the update. All reads can be directed to the leader for strong consistency, or to followers using lease-based mechanisms to prevent stale reads.

• Key Protocols: Raft, Paxos, and Zab (used in ZooKeeper).
• Benefit: Provides a clear, linearizable sequence of operations across the entire cluster.

These are the formal consistency models that define the strongest guarantees.

• Linearizability: The strongest model for single-object operations. It guarantees that operations appear to take effect instantaneously at some point between their invocation and completion. The result is as if all operations were executed in a single, global order that respects real-time ordering.
• Serializability: The strongest model for multi-object transactions. It guarantees that the outcome of executing a set of concurrent transactions is equivalent to some serial (one-at-a-time) execution of those transactions.

Enforcing these models typically requires distributed locking, two-phase commit (2PC), or consensus protocols, which add coordination overhead.

A protocol to ensure atomicity (all-or-nothing) across multiple nodes or shards, which is necessary for strong consistency in multi-shard writes.

• Phase 1 (Prepare): A coordinator asks all participating nodes if they can commit the transaction. Each node writes the transaction to its local log and votes "Yes" or "No."
• Phase 2 (Commit/Rollback): If all nodes vote "Yes," the coordinator sends a commit command. If any node votes "No," it sends a rollback command.

This ensures that a vector insertion with associated metadata, spread across different shards, either fully succeeds or fully fails, maintaining a consistent view. The downside is latency and blocking during the prepare phase.

While often associated with eventual consistency, vector clocks can be used in strongly consistent systems to detect and prevent conflicts. Each piece of data (e.g., a vector and its metadata) is tagged with a vector clock—a logical timestamp that tracks its update history across replicas.

Before committing a write, the system checks if the incoming write's clock descends from the current clock. If it does not (indicating a potential concurrent write from another client), the write can be rejected or forced through a synchronization point, requiring manual resolution or a predefined "last write wins" rule based on wall-clock time. This mechanism proactively avoids divergent data states.

Strong consistency is achieved by synchronizing nodes before acknowledging a write, which directly impacts performance.

• Increased Latency: The client must wait for the slowest node in the write quorum to respond. Network delays between geographically distributed data centers magnify this penalty.
• Reduced Availability: If replicas fail or a network partition occurs, the system may become unable to achieve a quorum, making it unavailable for writes to preserve consistency (as dictated by the CAP Theorem).
• Contrast: Asynchronous replication offers lower latency and higher availability but risks data loss on a primary failure and provides only eventual consistency.

Not all workloads require the overhead of strong consistency. Understanding alternatives is key to system design.

• Use Eventual Consistency For: Social media feeds, product recommendation caches, or activity logs where momentary staleness is acceptable.
• Use Session Consistency For: User-centric workflows, where a single user always sees their own writes, but other users' views may lag.
• Decision Framework: Ask: "What is the business cost of a stale read?" If the cost is high (financial loss, broken contract), choose strong consistency. If low (slightly outdated view), a weaker model improves performance and availability.

Eventual consistency is a model where, after a write, the system guarantees all replicas will converge to the same value eventually, but reads may temporarily return stale data. This contrasts with strong consistency and is often chosen in vector databases to prioritize low-latency reads and high availability for non-critical semantic search use cases.

• Trade-off: Favors latency and availability over immediate data freshness.
• Use Case: Suitable for recommendation systems where slight staleness is acceptable.

Synchronous replication is the mechanism that enforces strong consistency. A write operation is only acknowledged to the client after the data has been durably written to the primary node and all configured replica nodes. This ensures any subsequent read, regardless of the node it hits, will see the updated value.

• Impact: Introduces higher write latency proportional to network round-trip times to replicas.
• Guarantee: Provides the durability foundation for strong consistency.

A quorum is the minimum number of nodes in a distributed cluster that must participate in a read or write operation for it to succeed. It is used to enforce consistency policies despite node failures.

• Write Quorum (W): Number of nodes that must confirm a write.
• Read Quorum (R): Number of nodes queried for a read.
• Strong Consistency Rule: Setting R + W > N (where N is the replication factor) ensures a read always intersects with the most recent write, enforcing strong consistency.

Linearizability is the strongest form of consistency. It guarantees that operations appear to take effect instantaneously and in an order consistent with the real-time ordering of those operations. For vector databases, a linearizable system ensures that once a new embedding is indexed, all subsequent similarity searches will include it, providing a real-time, single-system view crucial for rapidly changing data.

A consistency model is the formal contract specifying how and when a write becomes visible to read operations across a distributed system. It defines the spectrum of guarantees.

• Strong Models: Linearizability, Sequential consistency.
• Weak Models: Eventual consistency, Causal consistency.
• Vector DB Context: The chosen model directly impacts query semantics, developer experience, and system performance. Selecting the right model is a key architectural decision balancing correctness needs with scalability goals.