NoSQL Data Stores
“NoSQL” is not one database model and does not mean “no schema” or “eventually consistent.” It covers key-value, document, wide-column, graph, time-series, search, and other specialized stores with different query, transaction, indexing, and distribution properties. Senior candidates avoid brand-first answers: they write the access-pattern matrix, identify invariants and data lifecycle, select a model, then explain partition keys, consistency, indexes, migrations, and failure recovery.
How to use this chapter
- Read the mental model and mechanics without taking notes.
- Close the page and explain the topic aloud in five minutes.
- Work the quantitative example on paper.
- Answer the question ladder without revealing the answer signals.
- Complete one design drill and score yourself with the senior checklist.
Learning objectives
- Compare key-value, document, wide-column, graph, time-series, and search-oriented models.
- Derive keys and denormalized records from read/write paths and transaction boundaries.
- Explain consistency, conditional writes, secondary indexes, and multi-item transaction trade-offs.
- Detect hot partitions, unbounded documents/rows, fan-out, and read/write amplification.
- Plan schema evolution, backfills, tombstone cleanup, rebalancing, and repair.
- Use polyglot storage without losing source-of-truth ownership and reconciliation.
Mental model
Model a distributed store as a set of records placed by a primary key, replicated under a consistency protocol, and served through a deliberately limited query surface. The limitations are often what make predictable distribution possible. A query that does not constrain the partition key may require fan-out to every partition, a separately maintained index, or a different materialized view.
Core mechanics
Key-value stores
A key-value store offers get, put, conditional update, and sometimes range/scan or TTL operations. It is excellent for sessions, feature state, idempotency records, counters, caches, and opaque blobs when the full access key is known. The value can still have schema, versioning, and validation even if the database does not interpret every field.
Design key namespaces, tenant isolation, maximum value size, TTL semantics, and conditional writes. A single key is often an atomic boundary, making compare-and-swap or version checks valuable. Large values increase network and replication amplification; tiny keys with huge traffic can become hot despite even keyspace distribution.
Document stores
Document databases store nested records and let queries/indexes address fields. Embedding is useful when child data shares lifecycle, is bounded, and is read with the parent. Referencing is better for independently changing, many-to-many, shared, or unbounded data. A customer document with a growing array of every order is a warning: updates rewrite/contend on one document and eventually hit size or latency limits.
Schema flexibility moves responsibility to application validation and migration strategy; it does not remove schema. Include a schema version, make readers tolerant during rollout, and backfill gradually. Secondary indexes enable richer queries but add synchronous/asynchronous maintenance and may have different consistency or partition behavior from primary-key reads.
Wide-column and partitioned-row stores
Wide-column systems commonly organize a partition key plus ordered clustering columns. All rows in a partition are colocated and can be scanned efficiently in clustering order. This is well suited to time buckets, device events, timelines, and precomputed query tables. It rewards query-first modeling: one logical entity may appear in several tables, each shaped for one access pattern.
Partition size and heat are first-class limits. device_id alone may create an unbounded lifetime partition; device_id + day bounds it but makes long-range reads touch many partitions. Add hash buckets when one tenant/time bucket is too hot, accepting read fan-out. Tombstones from deletes/TTL and anti-entropy repair can dominate latency if lifecycle is poorly designed.
Graph, search, and time-series specialization
Graph databases optimize traversals over vertices and edges, useful when variable-depth relationships are central and hard to precompute. They do not magically distribute arbitrary traversals; supernodes and cross-partition traversals remain difficult. Search engines build inverted indexes for text relevance, filtering, and aggregations, but are usually derived views rather than the transaction authority. Time-series databases specialize in timestamped ingest, compression, retention, downsampling, and window queries.
Specialized stores should have a bounded responsibility. Define how data arrives, replay/checkpoint behavior, freshness, deletion propagation, and rebuild time. A search index that cannot be rebuilt or reconciled has quietly become an ungoverned source of truth.
Partition keys and access locality
A good partition key spreads sustained and burst load, bounds data per partition, and colocates the operations that need low fan-out or atomicity. Candidate keys must be tested against real tenant sizes and popularity—not only distinct-count cardinality. Time prefixes can cause every new write to hit one partition; monotonically increasing IDs can have similar effects depending on partitioning implementation.
Composite strategies include tenant plus bucket, hash suffixes, and directory-based placement for exceptional tenants. Salting spreads writes but requires querying multiple buckets. Secondary indexes may conceal fan-out until scale. State maximum partitions touched per endpoint and what happens when a large tenant violates assumptions.
Consistency and conditional operations
Consistency varies by operation and topology. Some stores provide linearizable single-key reads/writes, tunable quorums, session guarantees, causal consistency, or eventual convergence. Specify the business need: read-your-writes for a user, monotonic reads, uniqueness, no lost updates, or globally ordered transitions. Do not use “strong consistency” without scope.
Conditional writes can protect versions, leases, idempotency records, and state transitions within a key. Multi-key transactions may exist but can carry cross-partition coordination and lower availability/throughput. Sometimes the better model makes one aggregate the atomic boundary; sometimes the business invariant truly requires a transactional system.
Replication, conflict, and repair
Leader-based stores serialize writes through a primary; leaderless designs may accept writes at multiple replicas and reconcile versions; multi-leader designs support disconnected or regional writes but expose conflicts. Last-write-wins is simple but can silently discard concurrent updates and depends on clock/tie behavior. Domain-aware merges, version vectors, CRDTs, or an explicit conflict workflow can preserve more intent.
Replication is not the same as repair. Nodes that miss writes need hinted delivery, log catch-up, read repair, Merkle-tree/anti-entropy comparison, or snapshot rebuild. Deletes need tombstones retained long enough that stale replicas do not resurrect data. Repair traffic and compaction require capacity separate from foreground load.
Denormalization and derived views
Multiple query-shaped records may be updated synchronously in one supported transaction, asynchronously through a log/CDC, or by a periodic rebuild. For asynchronous views, expose or tolerate freshness and make consumers idempotent. Store source version/event offset so stale updates cannot overwrite newer state.
Fan-out-on-write makes reads cheap but multiplies writes and creates backlog during celebrity-scale events. Fan-out-on-read keeps writes cheap but increases query merge cost. Hybrid designs materialize normal users and treat very large publishers specially. Quantify both directions and define recovery when the pipeline is hours behind.
Decision table
| Decision | Prefer the first option when… | Prefer the second option when… | Senior caveat |
|---|---|---|---|
| Key-value vs document | The application knows the complete key and treats value mostly as one unit. | Queries and updates need selected nested fields and secondary indexes. | Document flexibility still needs versioning, validation, and bounded document growth. |
| Embed vs reference | Data is bounded, shares lifecycle, and is almost always read with its parent. | Data changes independently, is shared, many-to-many, or unbounded. | Model from update contention and maximum size, not only convenience of one read. |
| One table/view vs several query tables | Access patterns share a key and ordering and write amplification matters. | Predictable low-latency queries require different partition/order shapes. | Every duplicate needs ownership, freshness, idempotency, and rebuild semantics. |
| Hash vs range partitioning | Even distribution and point access dominate. | Ordered range locality and scans dominate. | Range needs split/hotspot control; hash scatters ranges and analytics. |
| Single-region leader vs multi-region writes | Clear ordering and simpler conflict-free transactions matter. | Local write availability/latency during region isolation is essential. | Multi-write requires conflict semantics, not merely more replicas. |
| NoSQL vs relational authority | Aggregate-key operations and predictable denormalized access dominate. | Cross-record invariants, ad hoc joins, and transactional flexibility dominate. | A relational source with NoSQL read models is often a stronger hybrid than forcing one store. |
Quantitative reasoning
Failure modes and production signals
| Failure mode | What users see | Likely cause | Mitigation / design response | Useful signals |
|---|---|---|---|---|
| Hot partition | One shard throttles while cluster averages look healthy | Skewed tenant/key, temporal hotspot, celebrity traffic | Bucket/salt, isolate tenant, cache, rate limit, adaptive placement | Per-partition QPS/bytes/p99, top keys, throttle rate |
| Unbounded record | Updates and reads get slower; size limit failures | Ever-growing array/row/partition | Time/bucket child records, references, archival, hard limits | Record/partition size distribution, update bytes, compaction |
| Tombstone overload | Scans time out despite few live results | TTL/delete churn and delayed compaction/repair | Bucket lifecycle, tune retention/compaction, avoid broad scans, repair | Tombstones scanned, SSTables/segments, compaction debt |
| Secondary-index lag | Query omits recent items or returns stale fields | Asynchronous index maintenance/backlog | Document freshness, primary-key verify, backpressure, rebuild | Index lag/offset, mismatch samples, queue age |
| Conflict data loss | A user update disappears after convergence | Last-write-wins on concurrent writes | Conditional versions, merge semantics, CRDT/domain conflict, audit | Conflict rate, overwritten versions, clock skew |
| Repair storm | Latency spikes after node recovery | Anti-entropy/snapshot saturates disk/network | Throttle and prioritize repair, reserve capacity, staged recovery | Repair bytes/rate, disk queues, foreground p99 |
| Scatter-gather explosion | Tail latency grows with cluster size | Query lacks partition key or has many buckets | Dedicated index/view, cap fan-out, preaggregate, change API | Partitions/query, slowest shard, merge CPU, partial results |
Senior-level lenses
Access-pattern matrices beat category debates
For every endpoint, record key shape, sort/range, expected rows, payload, QPS, consistency, and atomicity. A store can be ideal for one operation and disastrous for another. This matrix also exposes when two stores or a derived index are justified.
Schema-on-read still has contracts
Flexible records require producer validation, reader compatibility, defaults, deprecation, and historical backfill. Without governance, every reader contains branching archaeology. Use versioned schemas and compatibility tests even when the database permits arbitrary fields.
Bound every dimension
Put limits on value size, children per document, rows per partition, query fan-out, result count, TTL horizon, retry count, and mutation rate. An “unbounded list” is a future outage. Senior candidates state what happens at the bound and how users paginate or archive.
Specialized indexes are disposable only when rebuildable
Search, recommendation, graph, and timeline views can be asynchronous, but the source event stream must be retained long enough and rebuild throughput must meet recovery goals. Track completeness and version—not merely process health.
Multi-region writes spend complexity on conflict
Local writes during partitions are valuable only if the domain has meaningful reconciliation. Shopping-cart union differs from username uniqueness or money movement. Present conflict frequency, user-visible outcome, audit, and repair—not a generic “eventual consistency” label.
Operational maturity is a selection criterion
A theoretically perfect data model can lose to weak backup, observability, migration, tooling, or team expertise. Include managed-service limits, local testing, restore process, on-call diagnostics, cost predictability, and exit/migration strategy in the decision.
Interview question ladder
What is NoSQL?
Show strong-answer signals
A family of non-relational or specialized models—not one guarantee—including key-value, document, wide-column, graph, search, and time-series systems.
What makes a good partition key?
Show strong-answer signals
Even heat and bounded size while colocating critical reads/atomic updates; test real skew and growth.
Why denormalize?
Show strong-answer signals
To serve known access patterns without joins/fan-out, accepting write amplification and synchronization/rebuild responsibility.
Embed orders in a customer document or reference them?
Show strong-answer signals
Orders are unbounded and independently queried/updated, so reference or bucket; embed bounded snapshots/profile children that share lifecycle.
Design a device-events key.
Show strong-answer signals
Device/tenant plus time bucket and ordered timestamp, optional hash suffix for hot devices; retention, range fan-out, late data, and partition limits.
How do you implement idempotent updates in a key-value store?
Show strong-answer signals
Operation key/unique token, conditional put/version, stored result/status, TTL based on replay window, and atomic relation to mutation.
Design a globally available shopping cart.
Show strong-answer signals
Per-user placement, local writes, item operation model/merge, conflict semantics, session guarantees, replication/repair, TTL, inventory distinction, observability.
A document-store workload has unpredictable p99 after growth. Diagnose.
Show strong-answer signals
Per-shard skew, document/array size, index selectivity, scatter queries, cache, lock/update contention, replication/compaction, plans and top tenants.
Choose a store for a social graph.
Show strong-answer signals
Enumerate traversals and depth, update rate, supernodes, consistency, partitioning, precomputed recommendations, source of truth, and whether adjacency lists in KV/SQL outperform a graph engine.
Move a query from fan-out to a materialized view.
Show strong-answer signals
Event/CDC source, idempotent consumer, ordering/version checks, backfill cut, dual-read comparison, lag SLO, repair/rebuild, deletion propagation.
Define a company-wide polyglot persistence policy.
Show strong-answer signals
Approved capabilities, workload decision records, ownership, schema/event standards, backup/RTO, data classification, cost, observability, lifecycle, and exception review.
Design automatic hot-tenant isolation.
Show strong-answer signals
Per-tenant telemetry, thresholds/hysteresis, directory placement, online copy+delta, fencing, routing epochs, capacity pool, rollback, billing and noisy-neighbor policy.
Design drills
Design ingest and query for 10 million devices, bursty writes, 13-month retention, recent dashboards, and rare long-range exports.
What the interviewer is testing
Key/bucket design, hot devices, lifecycle, rollups, and offline analytics.
Support multi-device and multi-region cart edits during partitions. Define record model, merge rules, inventory boundary, expiration, and conflict observability.
What the interviewer is testing
Domain-specific convergence rather than generic eventual consistency.
Build a product-search index from an authoritative catalog. Cover CDC, schema changes, backfill, freshness, delete/privacy propagation, and disaster rebuild.
What the interviewer is testing
Derived-store correctness and operational recovery.
Common weak answers and how to improve them
“NoSQL has no schema.”
Show the stronger answer
Schema responsibility moves; define versions, validation, compatibility, and migration.
“Use MongoDB because the data is JSON.”
Show the stronger answer
Choose from access patterns, invariants, partitioning, indexes, lifecycle, and operations—not wire shape.
“A UUID gives even distribution.”
Show the stronger answer
It may distribute keys, but tenant popularity, value size, and temporal access can still create hot nodes.
“Eventual consistency is faster.”
Show the stronger answer
State which operations may be stale, by how much, what session guarantees exist, and how conflicts/retries behave.
“Denormalize everything.”
Show the stronger answer
Bound amplification and define ownership, ordering, freshness, repair, and rebuild for each copy.