Skip to content

CONCEPT Cited by 2 sources

Tunable consistency

Tunable consistency is the property that a database lets applications choose the consistency + durability level per operation, rather than fixing one level for the whole system. The canonical realization is MongoDB's read concerns and write concerns: each individual read or write declares how many replicas must acknowledge, how deeply the write must be persisted, and whether it needs to see majority-committed state.

The one-size-fits-all problem

Traditional databases ship with a single consistency mode: SQL RDBMS → ACID, most early NoSQL systems → eventually consistent. This forces an architectural mistake: different data in the same application has different consistency needs, but a single-mode database forces the app to choose the worst-case level for all data — or to split across multiple databases.

MongoDB's framing:

"Not all data is created equal. Within a single application, some data — like a 'page view count' — might not have the same consistency requirements as an 'order checkout value'." — MongoDB (Source: sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse)

Without tunable consistency you get the multi-database problem for consistency reasons alone: one DB for loose-consistency counters, another for strictly-consistent checkout — with all the synchronization pain that creates.

Shape of the knob (MongoDB)

The spectrum MongoDB exposes:

  • "Fire and forget" — write is sent, no acknowledgement waited for. Fastest, weakest durability. Appropriate for page-view counters / similar telemetry that can tolerate loss.
  • Acknowledged writes to the primary — single-node durability.
  • Journaled writes — write sits in the WAL before ack.
  • Majority writes — a majority of voting replica-set members have the write before ack; the write survives a single-replica loss and is visible under majority reads.

Read concerns mirror this: local (whatever's on the node), majority (guaranteed-durable, survives failover), linearizable (real-time read-your-writes).

Why it unlocks single-database consolidation

With per-operation tuning, one logical database can host both the checkout and the page-view-counter workloads. The application picks:

  • Checkout write → w: "majority", j: true → fully ACKed, durable, majority-committed.
  • Page-view counter write → w: 0 or w: 1 → low-latency, tolerate loss.

This is the consistency-axis answer to the same three-database problem MongoDB's Vector Search addresses on the search-axis: reduce the number of specialised stores you operate by pushing the axis into the existing database.

Trade-offs

  • More cognitive load per write site — every write now has a consistency decision, and getting the wrong level ships a bug that's hard to detect in testing.
  • Visible to libraries / drivers — ORMs and drivers need to expose the knob; ad-hoc fire-and-forget defaults can silently lose writes.
  • Monitoring shifts — which write concern was used becomes a production-observability question (inflight writes tagged by concern).

Seen in

  • sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse — canonical MongoDB-side articulation: "This flexibility provides the best price/performance tradeoffs for modern applications." Named as one of four enterprise-grade improvements (HA replica sets, horizontal sharding, tunable consistency, multi-document ACID) that moved MongoDB from niche to system-of-record.
  • sources/2024-09-19-netflix-netflixs-key-value-data-abstraction-layer — Netflix's KV Data Abstraction Layer realises tunable consistency at the namespace level (via patterns/namespace-backed-storage-routing) instead of per-operation. Each namespace carries consistency_scope (e.g. LOCAL) and consistency_target (e.g. READ_YOUR_WRITES) as part of its persistence_configuration, and the DAL translates those into engine-specific quorum levels. Different axis from MongoDB (namespace-level vs operation-level) but the same underlying property: the platform exposes the knob so the application can declare its consistency need rather than inherit a one-size-fits-all default. Example given: ngsegment namespace → Cassandra primary with consistency_scope: LOCAL, consistency_target: READ_YOUR_WRITES + an EVCache cache tier.
Last updated · 542 distilled / 1,571 read