73 NoSQL Interview Questions and Answers (2026)

The four models differ in how they structure values and what query patterns they optimize: Key-Value (simplest lookup), Document (self-contained nested records), Wide-Column (sparse columnar rows at scale), and Graph (relationship-first traversal).

• Key-Value:

  • Opaque value retrieved by a single key; fastest possible lookups.

  • Best when: caching or session storage (e.g. Redis holding a user session), where you never query by value.

• Document:

  • Stores JSON/BSON documents with nested fields you can index and query.

  • Best when: a product catalog where each item has different attributes; the whole object loads in one read.

• Wide-Column:

  • Rows keyed by a partition key, with flexible sparse columns grouped into families.

  • Best when: massive write-heavy time-series or event logging (e.g. Cassandra ingesting IoT readings) needing linear write scaling.

• Graph:

  • Nodes and edges as first-class citizens with stored relationships.

  • Best when: fraud detection or social networks; "friends-of-friends" traversals that would be many costly joins elsewhere.

Vertical scaling (scale up) means adding more power (CPU, RAM) to a single machine; horizontal scaling (scale out) means adding more machines and spreading data across them. NoSQL is built for the latter because it relaxes the rigid consistency and join requirements that make distributing a relational database hard.

• Vertical scaling: Simple but hits a hardware ceiling and gets exponentially expensive; the single node remains a point of failure.

• Horizontal scaling: Add commodity nodes; capacity grows near-linearly and the cluster tolerates node failures.

• Why NoSQL fits horizontal scaling:

  • Data is partitioned (sharded) by key, so each node owns a slice independently.

  • Aggregate-oriented models avoid cross-node joins and multi-row ACID transactions, which are the things that make sharding a relational DB painful.

  • Many accept eventual consistency, easing replication across nodes.

Both retrieve a value by a key, but a key-value store treats the value as opaque (it doesn't look inside), while a document store understands the structure of the value and can index and query its internal fields. A document store is essentially a key-value store with a transparent, queryable value.

• Key-Value:

  • Value is a blob (string, JSON, binary); the DB only supports get/put by key.

  • Maximally fast and simple, but you can't query by anything except the key.

• Document:

  • Value is a structured document the DB parses; you can filter, index, and partially update fields.

  • Supports secondary indexes and rich queries (e.g. db.users.find({age: {$gt: 30}})).

• Net difference: transparency of the value drives query capability versus raw simplicity.

Sharding is horizontal partitioning: splitting a dataset across multiple nodes so each holds only a subset of the data. It enables horizontal scalability because you add capacity by adding cheap nodes rather than upgrading one machine, and load is divided among them.

• What it does:

  • Each shard stores a distinct slice of rows/documents, decided by a shard key.

  • Total dataset and throughput exceed what any single node could hold or serve.

• How keys map to shards:

  • Hash-based: hash the key for even distribution (loses range-query locality).

  • Range-based: contiguous key ranges per shard (good for ranges, risks hotspots).

  • Consistent hashing is common to minimize data movement when shards change.

• Why it scales horizontally:

  • Reads/writes for different keys hit different nodes, so throughput grows roughly linearly with node count.

  • Combined with replication, shards also get fault tolerance.

• Costs:

  • Cross-shard queries, joins, and transactions become expensive or unsupported.

  • A poor shard key causes uneven distribution (the same hot-partition problem).

Object (blob) storage stores data as discrete objects (a blob of bytes plus metadata and a unique key) in a flat namespace addressed by key, rather than as files in a tree or rows in a table. It is non-relational because it abandons schemas, joins, and query languages entirely in favor of massive, cheap, durable storage you fetch by key.

• What an object is:

  • The data (any bytes: images, video, backups, logs), a unique key/path, and metadata; typically accessed over HTTP APIs (e.g., S3-style GET/PUT).

  • Examples: Amazon S3, Azure Blob Storage, Google Cloud Storage.

• Where it fits in the NoSQL landscape:

  • Like key-value stores, access is by key, with no schema or relational querying; it scales horizontally to petabytes with high durability via replication.

  • Difference: objects are large, opaque, and immutable-ish (you replace, not edit in place), optimized for throughput, not low-latency record ops.

• Typical use: Storing large binary assets while keeping a small reference (URL/key) in a database; backups, data lakes, static content.

• Trade-off: No rich queries or transactions across objects; you must build indexing/search elsewhere if you need it.

TTL is a per-record (or per-collection) setting that tells the database to automatically expire and delete data after a defined time, so you don't have to run manual cleanup. A background process periodically scans for expired entries and removes them, which keeps datasets bounded and ideal for transient data.

• How it's expressed: Either a duration from write (e.g., Redis EXPIRE key 3600) or an absolute timestamp field with a TTL index (e.g., MongoDB expireAfterSeconds).

• Lazy vs. background deletion:

  • Expiry is often eventual: a background reaper runs on an interval, so data may linger briefly past its TTL.

  • Some stores also delete lazily on access (the read finds it expired and removes it).

• Common use cases:

  • Session tokens, caches, rate-limit counters, OTPs, and short-lived feature flags.

  • Compliance-driven data retention (auto-purge after N days) and rolling time-series/log data.

• Caveat: Don't rely on exact-instant deletion; if precise expiry matters, check the timestamp on read rather than trusting the reaper's timing.

Choose NoSQL when your scale, data shape, or access pattern fights the relational model: huge horizontal scale, flexible/evolving schemas, or known query patterns that map to a denormalized model. In exchange you usually give up rich ad-hoc joins, strong multi-record transactions, and strong consistency by default.

• Good fits:

  • Massive write/read volume needing horizontal scale across commodity nodes (Cassandra, DynamoDB).

  • Flexible or rapidly evolving schema and semi-structured data (document stores like MongoDB).

  • Well-known, denormalized access patterns: model the data to match the query.

  • Specialized shapes: graphs, time series, wide-column, key-value caches.

• Trade-offs you accept:

  • Weaker transactional guarantees: often eventual consistency, limited multi-record ACID, pushing logic (Sagas, idempotency) into the app.

  • Limited ad-hoc querying and joins: data duplication and denormalization become your job, and new query patterns may force remodeling.

  • Operational/data integrity moves to the application (no foreign keys, fewer constraints).

• Rule of thumb: pick NoSQL for scale + known access patterns; don't pick it just to avoid schema design.

A wide-column store organizes data by rows that can each hold a huge number of dynamic columns, grouped into column families, and it physically stores data column-family-wise rather than row-wise: this makes it sparse-friendly and built for write throughput at scale.

• Schema is flexible per row:

  • Each row can have different columns; a relational table forces every row into the same fixed columns (with NULLs for missing values).

  • No storage cost for absent columns: ideal for sparse data with millions of possible attributes.

• Storage layout:

  • Data is grouped by column family and keyed by a partition key, so related columns sit together on disk.

  • A relational engine typically stores entire rows contiguously, optimized for reading full records.

• Designed for distribution: The partition key decides which node owns the data, enabling horizontal scaling and fast writes (e.g. Cassandra, HBase).

• Query trade-off: you query along the partition/clustering keys, not arbitrary ad-hoc joins like SQL.

Impedance mismatch is the friction between an application's in-memory object model (nested objects, lists, references) and the flat, tabular relational model: objects must be shredded across many tables and reassembled, requiring an ORM and joins. Document NoSQL reduces this by storing data in the same shape the application uses.

• The mismatch:

  • An object like an order with nested line items maps to several normalized tables.

  • Reads/writes need joins and an ORM to translate rows back into objects, adding complexity and overhead.

• How document stores solve it:

  • The nested object is persisted as a single JSON/BSON document, matching the application structure directly.

  • One read returns the whole aggregate: no joins, less translation code.

• Trade-off: Denormalization can duplicate data and complicate updates; you optimize for read patterns instead of normalization.

A graph database wins when queries are about relationships and traversals of variable, often deep, depth: it stores edges as direct pointers between nodes, so following them is constant-time per hop rather than a join that scales with table size.

• Deep, multi-hop traversals: "Friends of friends of friends" or shortest-path queries explode into many self-joins in SQL; a graph just walks edges.

• Index-free adjacency: Each node physically references its neighbors, so traversal cost depends on the result size, not total dataset size.

• Relationship-centric domains: Fraud rings, recommendation engines, social graphs, network/dependency mapping.

• When NOT to use it: Simple key lookups or bulk aggregate scans: a key-value or document store is simpler and faster.

The CAP theorem states that a distributed system can guarantee at most two of Consistency, Availability, and Partition tolerance simultaneously. Since network partitions are unavoidable in distributed systems, P is not optional: when one happens you must choose between staying Consistent (reject requests that can't be confirmed) or staying Available (serve possibly stale data).

• The three properties:

  • Consistency: every read sees the latest write (or an error).

  • Availability: every request gets a non-error response.

  • Partition tolerance: the system keeps working despite dropped messages between nodes.

• Why it's really a C-vs-A choice: During a partition, a node either refuses to answer until it can sync (chooses C) or answers from its local state (chooses A); it can't do both.

• Prioritize Consistency (CP): A banking ledger: better to reject a withdrawal than risk a double-spend on stale data.

• Prioritize Availability (AP): A shopping cart or social feed: showing slightly stale data beats showing an error; reconcile later.

ACID guarantees correctness with strict transactional guarantees, while BASE trades immediate consistency for availability and scale: it accepts that data converges over time rather than being correct on every read.

• ACID (relational):

  • Atomicity: all-or-nothing transactions.

  • Consistency: every transaction moves the DB between valid states (constraints hold).

  • Isolation: concurrent transactions don't interfere.

  • Durability: committed data survives crashes.

• BASE (NoSQL):

  • Basically Available: the system answers requests even if some nodes fail.

  • Soft State: replica state may keep changing over time without new input, as updates propagate in the background.

  • Eventual Consistency: if writes stop, all replicas eventually converge to the same value.

• Soft State in practice: You can't assume the value you read is the final one: another replica may hold a newer copy still syncing.

• Eventual Consistency in practice: A write to one node is visible immediately there but takes milliseconds to seconds to reach others (replication lag).

• Trade-off: ACID favors correctness for transactional systems (banking); BASE favors availability and horizontal scale (large web/distributed systems).

Eventual consistency means that, in the absence of new writes, all replicas will eventually converge to the same value, but for a window of time different replicas can return different (stale) results.

• What it guarantees: Convergence over time, not instant agreement: no bound on when, just that it happens once propagation completes.

• Risks for the end-user:

  • Stale reads: seeing an old value (e.g. a profile update not yet visible).

  • Lost-update / conflicting writes if two replicas accept concurrent writes.

  • Non-monotonic reads: reading a newer value, then an older one from a lagging replica.

• Application-level mitigations:

  • Read-your-writes / session consistency: route a user to a replica that has their write or read from the primary after writing.

  • Quorum reads/writes (R + W > N) for keys that need freshness.

  • Conflict resolution: versioning, vector clocks, or CRDTs instead of blind last-write-wins.

  • UX tricks: optimistic UI that shows the user's own change locally while it propagates.

Strong consistency guarantees every read sees the latest write; eventual consistency only promises convergence over time; causal consistency sits between, preserving the order of operations that are causally related while allowing unrelated ones to be seen in any order. A bank balance needs strong consistency; a social feed is fine with eventual (often causal) consistency.

• Strong consistency: All clients see a single, up-to-date value; higher latency and lower availability during partitions.

• Eventual consistency: Replicas converge eventually; reads may be stale, but availability and latency are excellent.

• Causal consistency:

  • Preserves cause-and-effect ordering: if a reply depends on a post, no one sees the reply before the post.

  • Concurrent, unrelated updates can still appear in different orders.

• Choosing:

  • Social feed: eventual/causal is ideal: stale-by-seconds is harmless, and causal ordering keeps comment threads coherent.

  • Bank balance: strong consistency: a stale or out-of-order read could allow overdrafts or double-spends.

CAP says during a network partition a distributed system must sacrifice either consistency or availability. A CP system rejects/blocks requests to stay consistent; an AP system keeps serving requests but may return stale or divergent data.

• During a partition: The cluster splits into groups that can't communicate, so they can't synchronize writes.

• CP behavior (consistency over availability):

  • Nodes that can't reach a quorum refuse reads/writes (errors or timeouts) rather than serve possibly-stale data.

  • Examples: MongoDB (majority writes), HBase.

• AP behavior (availability over consistency):

  • Every reachable node keeps answering, accepting writes on both sides; divergent values are reconciled later.

  • Examples: Cassandra, DynamoDB (tunable).

• Note: when there's no partition, both can offer strong consistency and availability; CAP only forces the choice during a partition (and PACELC adds the latency trade-off otherwise).

Read-your-writes consistency ensures a user always sees the result of their own writes on subsequent reads, even if other clients might still see stale data. In an eventually consistent system it's implemented by steering that user's reads toward data known to include their write.

• What it guarantees: A per-session/per-user promise: your own updates never disappear from your view.

• Common implementations:

  • Sticky sessions: route the user to the same replica (or primary) for both write and follow-up reads.

  • Version tracking: store the latest write version/timestamp in the session and only read from replicas that have caught up to it.

  • Read-from-primary window: serve reads from the leader for a short time after a write.

  • Quorum (R + W > N): force read/write set overlap so the latest write is always visible.

• Why bother: It removes the most jarring symptom of eventual consistency (seeing your own change vanish) without the cost of full strong consistency.

Strong consistency means every read returns the most recent committed write, so all clients always see one agreed-upon value. Eventual consistency only guarantees that replicas converge to the same value over time, so reads can temporarily be stale.

• Strong consistency:

  • Reads reflect the latest write immediately, usually via synchronous replication or quorum.

  • Cost: higher latency and reduced availability during failures/partitions.

• Eventual consistency:

  • Writes propagate asynchronously; a read may return an older value until replicas sync.

  • Benefit: low latency, high availability, easy horizontal scaling.

• Acceptable example:

  • A like/view counter on a social post or YouTube video: showing 1,000 vs 1,003 for a few seconds harms nothing, and the count converges shortly after.

  • Contrast: a bank balance or inventory count needs strong consistency to avoid overdrafts/overselling.

Partition tolerance means the system keeps operating even when network failures split it into groups of nodes that cannot communicate. It is non-negotiable because partitions are not a design choice: they will happen in any real distributed system, so you must tolerate them.

• What a partition is:

  • A break in communication between nodes (dropped packets, switch failure, datacenter link down) so messages between two subsets are lost or delayed.

  • Each side may still be alive and serving clients, just unable to coordinate with the other.

• Why it is non-negotiable:

  • Networks are unreliable by nature: you cannot prevent partitions, only respond to them.

  • A single-node system can drop the P, but the moment data spans machines, partitions are inevitable.

• How it reframes CAP:

  • Since P must be tolerated, the real choice during a partition is between C (consistency) and A (availability).

  • CP systems refuse requests they can't make consistent; AP systems answer anyway and reconcile later.

  • When there is no partition, a system can offer both C and A.

Durability is about not losing a write once it's acknowledged; consistency is about all readers seeing the same, correct value. They are independent guarantees, and NoSQL systems tune both through replication and write-acknowledgment settings.

• Durability:

  • A confirmed write survives crashes (persisted to disk and/or replicated to enough nodes).

  • Controlled by write concern: e.g. acknowledged by the primary only, or by a majority of replicas.

• Consistency:

  • Whether a subsequent read reflects the latest write across all replicas.

  • Ranges from strong (read your latest write everywhere) to eventual (replicas converge over time).

• How NoSQL trades them off:

  • Quorum tuning: with N replicas, choosing read (R) and write (W) counts where W + R > N gives strong reads at the cost of latency.

  • Lower W (e.g. W=1) means faster, less durable writes; higher W means more durable but slower.

  • A write can be durable but not yet consistent: persisted on the primary while replicas still lag.

Schema-on-write enforces structure when data is inserted (like a relational table); schema-on-read stores data as-is and applies structure when you query it. The trade-off is upfront validation and fast typed reads versus ingestion flexibility and deferred interpretation cost.

• Schema-on-write:

  • The database validates and rejects malformed data at insert time.

  • Lifecycle: changing the schema needs migrations, but data is guaranteed clean and uniform.

  • Query performance: reads are fast since structure and types are known and indexable.

• Schema-on-read:

  • Any shape is accepted; the application interprets fields at read time.

  • Lifecycle: rapid iteration and no migrations, but the app must defensively handle missing/varied fields.

  • Query performance: parsing and coercion happen per read, and old/new shapes coexist, adding logic overhead.

• Practical note: Most document stores are schema-on-read by default but offer optional validation to claw back guarantees where needed.

Embed when the child is read together with the parent and is owned by it; reference when the child is large, shared, unbounded, or updated independently. The decision balances single-read access against document size and atomic write boundaries.

• Favor embedding when:

  • The child is accessed with its parent ("contains" / one-to-few relationship).

  • You want one read to fetch everything: no joins, faster reads.

  • Parent and child update together: a single document write is atomic.

• Favor referencing when:

  • The child is large or the array is unbounded (risking hitting document size limits, e.g. 16MB in MongoDB).

  • The child is shared by many parents (avoid duplicating and re-updating it everywhere).

  • Child and parent change at different rates or independently.

• Impacts to weigh:

  • Read: embedding = one lookup; referencing = multiple round trips or a client-side join.

  • Write atomicity: a single document write is atomic, so embedding keeps related changes consistent; references split writes across documents (no multi-doc atomicity without transactions).

Query-driven design means you start from the access patterns (the exact queries your app will run) and model the data to serve them efficiently, rather than modeling "correct" entities first. It inverts the relational habit of normalizing into clean tables and figuring out queries later.

• The relational approach:

  • Normalize entities into tables to remove redundancy, then use flexible joins and ad-hoc queries at runtime.

  • The schema is query-agnostic: the engine assembles answers via joins on demand.

• The NoSQL query-driven approach:

  • List your access patterns first, then shape collections/items so each query is a single, cheap lookup.

  • Joins are expensive or unavailable, so data is pre-joined and denormalized into the shape the read needs.

• Why the shift:

  • NoSQL trades flexible querying for scale and predictable latency: optimizing for known patterns is what makes that scale work.

  • Downside: a new, unanticipated access pattern may require remodeling or a new copy of the data.

Denormalization (storing redundant copies of data) is first-class in NoSQL because it eliminates expensive joins and lets each query hit one place, which is essential for scale and low latency. The cost is duplicated data that can drift out of sync, so updates must be deliberately propagated.

• Why it's embraced:

  • No (or expensive) joins: pre-joining data into one item makes reads a single fast lookup.

  • It supports horizontal scaling, since reads stay on one partition instead of fanning out.

• Risks of duplication:

  • Update anomalies: a value changes in one copy but not others, causing inconsistency.

  • More storage and more write work, since one logical change touches many records.

• Handling updates to duplicated data:

  • Only duplicate fields that rarely change (e.g. a user's name alongside their orders).

  • Fan-out updates: write to all copies, often asynchronously via background jobs or change streams / CDC.

  • Accept eventual consistency: copies converge after a short delay, which is usually fine for read-optimized data.

Without server-side joins, you model relationships by either embedding related data inside a document or by referencing it and resolving the link in the application: the choice depends on cardinality, data size, and access patterns.

• One-to-Many:

  • Embed the "many" side when the children are bounded and read with the parent (e.g. an order with its line items).

  • Reference when the "many" side is large or unbounded: store a parent ID on each child, or an array of child IDs on the parent.

  • Rule of thumb: "one-to-few" embed, "one-to-many" reference, "one-to-squillions" always reference (parent ID on child).

• Many-to-Many:

  • Store arrays of references on one or both sides, accepting that you read both and resolve in the app.

  • Or duplicate a small subset of the related entity's fields to avoid a second lookup (denormalization).

• Application-side joins: You issue follow-up queries by ID and stitch results in code; some databases offer helpers ($lookup in MongoDB) but they don't scale like an RDBMS join.

• Trade-off: Embedding favors read performance and atomic updates but risks large/duplicated documents; referencing keeps data normalized but costs extra round trips.

An aggregate is a cluster of related data treated as a single unit (a document, row, or key-value entry) with one entity as its root. Aggregate-oriented design means storing together what you read and write together, which is exactly how most NoSQL stores want data shaped.

• What an aggregate is:

  • A self-contained boundary (e.g. an order plus its line items and shipping address) accessed and updated as a whole.

  • The term comes from Domain-Driven Design's "aggregate root."

• Why NoSQL favors it:

  • Most NoSQL systems provide atomicity only within a single aggregate, so the boundary is also the consistency and transaction boundary.

  • An aggregate maps cleanly to one document/partition, so one read fetches everything and one write commits atomically.

  • It also distributes well: aggregates are the natural unit to shard across nodes.

• Implication for modeling:

  • You design around access patterns: data used together lives in the same aggregate, even if that duplicates fields.

  • Relationships that span aggregates must be resolved by the application, not by joins.

Denormalization trades cheap reads for harder writes: when a duplicated field changes, you must fan the update out to every copy. Since most NoSQL stores lack multi-document transactions, you keep copies in sync with batched/async update jobs, careful schema choices, and tolerance for brief inconsistency.

• Decide what to duplicate:

  • Duplicate fields that rarely change (a user's name) and avoid duplicating volatile ones.

  • Keep an authoritative "source of truth" copy so you always know which value is canonical.

• Patterns to keep it in sync:

  • Multi-write / batch: update all copies in one logical operation (e.g. a batch write) where the database allows it.

  • Event-driven propagation: emit a change event and let a consumer (or change-data-capture stream) update the duplicates asynchronously.

  • Background reconciliation jobs sweep and repair drift periodically.

• Accept eventual consistency: Copies may lag briefly; design so that's acceptable, and make updates idempotent so retries are safe.

• Avoid duplication when you can't tolerate drift: If a value must always be consistent and changes often, reference it instead and pay the extra read.

A composite primary key splits into a partition key (which determines where the data lives) and a sort key (which orders items within that partition). The sort key turns a single partition into an ordered collection you can range-scan, enabling many access patterns from one key.

• Two parts, two jobs:

  • Partition key: groups and locates related items on the same node.

  • Sort key (clustering key in Cassandra): orders items inside the partition and uniquely identifies each.

• Access patterns it unlocks:

  • Range queries: "all orders for user X between two dates" by querying the partition and a sort-key range.

  • Top-N / latest: read in descending sort order with a limit.

  • Begins-with / prefix queries on string sort keys.

• Single-table modeling: Encoding type into the sort key (e.g. ORDER#2024, PROFILE#) lets one partition hold several entity types, fetched together in one query.

• Caveat: You can only range-scan within a single partition; spanning partitions still needs a scan or a secondary index.

Range partitioning assigns contiguous key ranges to nodes, while hash partitioning applies a hash function to the key and places it by hash value. Range partitioning is far better for range queries; hash partitioning gives more even data distribution.

• Range-based:

  • Keys stay in sorted order, so a range query (e.g. dates A to B) hits one or few contiguous partitions efficiently.

  • Risk: sequential or skewed keys (timestamps, auto-increment IDs) pile writes onto one partition, creating hotspots.

• Hash-based:

  • Hashing scatters keys uniformly, so load and storage spread evenly across nodes.

  • Cost: order is destroyed, so a range query must fan out to all partitions (a scatter-gather).

• The core trade-off:

  • Range = query locality but risk of uneven/hot distribution.

  • Hash = even distribution but no efficient ordered scans.

• Hybrid: Many systems hash the partition key but keep a sorted sort/clustering key within each partition, getting both even spread across partitions and ordered access inside one.

A good partition key spreads data and traffic evenly across all partitions while still letting common queries hit a single partition. Choose one with high cardinality and uniform access; a low-cardinality or skewed key concentrates load on one partition and bottlenecks the whole cluster.

• Properties of a good key:

  • High cardinality: many distinct values so data distributes across many partitions.

  • Even access pattern: reads/writes spread across keys rather than hammering a few.

  • Query alignment: the values your queries filter on should map to a single partition.

• Low cardinality: Few distinct values (e.g. a boolean or country) means data piles into a handful of partitions, defeating horizontal scaling.

• Hot partition:

  • One partition receives a disproportionate share of traffic (e.g. partitioning by date and writing only today, or a celebrity user ID).

  • That node saturates CPU/IO and throttles while others sit idle, causing latency spikes and timeouts.

• Mitigations:

  • Add a composite or compound key to increase cardinality.

  • Salt or bucket hot keys (append a random suffix) to fan writes across partitions.

A quorum is the minimum number of replica nodes that must acknowledge a read or write for the operation to be considered successful. It is the tunable mechanism that trades consistency against availability; if a quorum can't be reached, the operation fails rather than risk diverging data.

• The core formula:

  • With N replicas, a write needs W acks and a read needs R responses.

  • If W + R > N, reads and writes overlap on at least one node, guaranteeing strong (read-your-writes) consistency.

• Tuning the trade-off:

  • Higher W/R gives stronger consistency but lower availability and higher latency.

  • Lower values favor availability and speed but risk stale reads.

• When quorum can't be reached:

  • Too many replicas are down/partitioned to satisfy W, so the write is rejected and the client gets an error.

  • This is the CAP choice: a CP system sacrifices availability to avoid inconsistent writes.

  • Some systems allow hinted handoff or lower consistency levels (e.g. Cassandra's ANY) to keep accepting writes, trading durability/consistency for availability.

Polyglot persistence is using multiple, different data stores within one system, each chosen because it fits a specific data shape and access pattern, instead of forcing everything into one database. A microservices architecture naturally enables this since each service owns its data and can pick the best-fit store.

• The core idea:

  • No single database is optimal for every workload, so match the tool to the data model and queries.

  • Microservices' decentralized, per-service databases make mixing engines practical.

• Document store for entity data:

  • Stores self-contained, hierarchical records (a product, a user profile) read/written as a whole.

  • Flexible schema and fast key/document lookups for the catalog or profile service.

• Graph database for relationships:

  • Excels at deep, multi-hop traversals (friends-of-friends, recommendations, fraud rings) that would be costly joins elsewhere.

  • Relationships are first-class, so connection-heavy queries stay fast.

• Why both together: E-commerce: documents hold product/order details; the graph powers 'customers who bought this also bought' across the same entities.

• Trade-offs: More operational complexity, plus the burden of keeping data consistent across stores (often via events).

MapReduce is a programming model for processing large datasets in parallel by splitting work into two functions: a map that transforms and emits key/value pairs, and a reduce that aggregates values sharing a key. NoSQL systems use it to run analytics across data distributed over many nodes by moving computation to where the data lives.

• The two phases:

  • Map: runs on each shard locally, processing records and emitting intermediate (key, value) pairs.

  • Shuffle/sort: groups all values by key across nodes (the implicit middle step).

  • Reduce: combines the grouped values into a final result per key (sum, count, etc.).

• Why it suits NoSQL:

  • Data is already partitioned across nodes, so maps run in parallel near the data, minimizing network movement.

  • Scales horizontally and tolerates node failures by re-running failed tasks.

• Where it's used:

  • Batch aggregation/analytics in stores like MongoDB, CouchDB, and Hadoop-backed systems.

  • Largely superseded for ad-hoc queries by aggregation pipelines and SQL-on-NoSQL engines, which are easier and often faster.

A time-series database is optimized for data points indexed by time (metrics, sensor readings, events), where writes are overwhelmingly appends of recent timestamps and queries are time-range scans and aggregations. NoSQL stores fit this well because their write-optimized, horizontally scalable designs match the append-heavy, high-volume nature of time-series workloads.

• Defining workload traits:

  • Extremely high, append-only ingest of timestamped points; data is rarely updated.

  • Queries are dominated by time ranges, downsampling, and rollups (avg/min/max over windows).

  • Old data is aged out via retention/TTL policies.

• Why NoSQL stores fit:

  • LSM-tree storage (e.g. Cassandra) makes sequential writes cheap, matching constant ingest.

  • Partitioning by series + time bucket keeps a time range on one partition and spreads load across many.

  • Native TTL expires stale data automatically, no costly deletes.

  • Horizontal scaling absorbs growing data volume by adding nodes.

  • Columnar layout and compression of similar adjacent values cut storage dramatically.

• Caveat: Choose the partition key carefully: bucketing by time avoids a single ever-growing hot partition for the current window.

A search-oriented NoSQL database (e.g., Elasticsearch or OpenSearch) is built to index and rank text by relevance, not just store and fetch records: it analyzes text into tokens and uses an inverted index so queries like "find documents matching these words, ranked by relevance" run fast. You reach for one when querying is about relevance, fuzzy matching, and aggregation rather than primary-key lookups.

• Core mechanism: the inverted index:

  • Text is run through analyzers (tokenizing, lowercasing, stemming, stop-word removal) and stored as a term-to-document map.

  • Queries are scored (e.g., BM25) so results come back ranked by relevance, not just matched.

• What it does well: Full-text search, fuzzy/typo-tolerant matching, autocomplete, faceting, and analytics-style aggregations over large text corpora.

• When to choose it over a document store:

  • Document stores (e.g., MongoDB) excel at fetching whole documents by key/field, but their text search is limited and unscored by comparison.

  • Use a search engine when relevance ranking, linguistic analysis, or rich aggregations dominate your read patterns.

• Caveat: it is usually a secondary, eventually-consistent index, not your system of record: Common pattern: keep authoritative data in a primary store and sync it into the search engine for querying.

Index-free adjacency means each node in a native graph database stores direct physical pointers to its adjacent nodes and relationships, so traversing an edge is a pointer hop rather than a global index lookup. This makes relationship traversals fast because the cost depends on how much of the graph you actually walk, not on the total size of the dataset.

• How it works: A node holds references to its relationships, which reference neighbor nodes directly: "follow the pointer" instead of "search an index."

• Why it's fast:

  • Traversal cost is local: O(neighbors visited), roughly constant per hop regardless of how many total nodes exist.

  • Contrast with relational/document approaches: a join or lookup typically scans/searches an index (e.g., O(log n)) for every hop, and multi-hop queries compound that cost.

• Concrete impact: Deep queries ("friends of friends of friends", shortest path, recommendation paths) stay performant where repeated SQL joins degrade badly.

• Caveat: You still need indexes to find the starting node(s); index-free adjacency speeds the traversal after that entry point.

In a wide-column model (e.g., Cassandra, HBase), each row can have its own set of columns, and a column simply isn't stored if it has no value for that row. Sparse data costs essentially nothing because absent columns occupy no space, unlike a fixed relational schema where every row reserves a slot for every column.

• Storage is per-cell, not per-row-schema:

  • Data is stored as (row key, column name, value) units, so only the columns that actually exist for a row are written.

  • Two rows in the same table can have completely different columns.

• Why this beats fixed relational columns for sparse data:

  • In a relational table, a missing value is still a NULL placeholder occupying a defined column; thousands of optional attributes mean wide, mostly-NULL rows.

  • Wide-column avoids that waste and avoids schema migrations when new attributes appear: just write a new column name.

• Practical fit: Great for data with many possible-but-rarely-present attributes (sensor readings, user feature flags, event metadata) and millions of rows.

• Trade-off: Flexibility shifts the burden to the application/query design; you model around access patterns, not normalized relations.

Replication lag is the delay between a write being committed on the leader and that write becoming visible on a follower replica. Because replication is asynchronous, a read served by a lagging follower can return outdated data, a stale read, even though the leader already has the newer value.

• Why lag happens:

  • The leader acknowledges the write and applies it locally, then ships the change log to followers asynchronously over the network.

  • Followers fall behind under heavy write load, slow networks, or expensive apply operations.

• How it causes stale reads:

  • To scale reads, applications route queries to followers; a follower that hasn't applied the latest write returns an old value.

  • Classic symptom: a user updates their profile, the write hits the leader, but their next read hits a stale follower and shows the old data ("read-your-writes" violation).

• Mitigations:

  • Read-your-writes: route a user's reads to the leader (or a replica known to be caught up) for a short window after they write.

  • Monotonic reads: pin a user to one replica so they never see time go backwards.

  • Use synchronous/quorum reads when freshness matters, accepting higher latency.

In leader-based replication all writes go through a single leader that propagates them to followers; in leaderless replication any replica accepts writes and consistency is achieved by writing to/reading from a quorum. The core trade-off: leaderless keeps accepting writes even when nodes fail, at the cost of more conflicts and weaker ordering.

• Leader-based (master-slave):

  • One node serializes all writes, giving a clean ordering and simple conflict-free replication to followers.

  • Write availability depends on the leader: if it fails, writes stall until failover (election) completes.

  • Examples: PostgreSQL replication, MongoDB replica sets.

• Leaderless (Dynamo-style):

  • Client (or coordinator) writes to several replicas; a write succeeds once W replicas ack, reads query R replicas.

  • With W + R > N you get quorum overlap for strong-ish consistency.

  • No single point of write failure: as long as W replicas are up, writes proceed.

  • Examples: Cassandra, Riak, DynamoDB.

• Trade-offs:

  • Leaderless maximizes write availability and is tolerant of node/network failures.

  • But concurrent writes to different replicas create conflicts needing resolution (vector clocks, LWW, CRDTs, read repair).

  • Leader-based simplifies consistency and conflict handling but trades availability during failover.

Idempotency means applying the same write more than once produces the same final state as applying it once. It's critical because in distributed systems a client can't tell whether a timed-out request actually succeeded, so it retries: without idempotency that retry could double-charge, double-insert, or corrupt counters.

• Why retries are unavoidable: A network failure may drop the response after the write committed; the client retries blindly to ensure delivery (at-least-once semantics).

• Naturally idempotent vs not:

  • Idempotent: setting an absolute value, upsert by primary key, deleting a key.

  • Not idempotent: relative updates like increment counters or append to a list.

• How to make writes idempotent:

  • Attach a client-generated idempotency key / request ID and dedupe on the server.

  • Use conditional writes (compare-and-set, "insert if not exists") so a repeat is a no-op.

• Ties directly to Sagas: since each saga step may be retried, the steps and their compensations must be idempotent.

Choose a relational database when data is highly structured and relational, when you need strong ACID transactions, and when you want flexible ad-hoc queries via SQL. The trade-offs are a rigid (but enforced) schema and a model that scales primarily by vertical scaling, with horizontal scaling being harder than in most NoSQL systems.

• When relational wins:

  • Complex relationships and joins across many entities.

  • Strong consistency and multi-record ACID transactions (financial, inventory, bookings).

  • Unpredictable, ad-hoc queries and reporting where SQL flexibility matters.

  • Data integrity enforced by the engine: constraints, foreign keys, unique indexes.

• Schema flexibility trade-off: A fixed schema gives strong validation and integrity but requires migrations to evolve, which can be heavy at scale.

• Vertical vs horizontal scaling trade-off:

  • Relational DBs scale up well (bigger machine) but distributing writes across nodes is hard: joins and transactions don't naturally shard.

  • NoSQL is built to scale out; with RDBMS you reach for read replicas, sharding, or partitioning, which add complexity.

NoSQL is the wrong choice when you need rich relational queries, strong transactional integrity, or when you adopt it without understanding your access patterns. The classic anti-pattern is treating a NoSQL store like a relational database: doing application-side joins, normalizing heavily, or expecting ACID where there is none.

• Wrong-fit situations:

  • Highly relational data needing many joins: forcing this into documents or app-side joins is slow and error-prone.

  • Strong transactional needs (money, inventory) where eventual consistency causes real bugs.

  • Unknown or constantly changing query patterns: NoSQL rewards modeling around known queries, so ad-hoc analytics suffer.

• Modeling anti-patterns:

  • Over-normalizing in a document store, then stitching data together in code.

  • Bad partition/shard key choice causing hot partitions and skew.

  • Unbounded documents/rows (ever-growing arrays) or mass deletes that create tombstone storms.

• Process anti-pattern: Choosing NoSQL for hype or to "avoid schema design" rather than for a concrete scale or access-pattern reason.

PACELC extends CAP by addressing the normal case CAP ignores: if there is a Partition, you trade Availability vs Consistency (the CAP part); Else (no partition), you still trade Latency vs Consistency. It captures that even a healthy system pays a latency cost for strong consistency.

• The formula:

  • PAC: during a partition, choose Availability or Consistency.

  • ELC: else (normal operation), choose Latency or Consistency.

• Why latency vs consistency exists without a partition:

  • Strong consistency requires waiting for a quorum of replicas to acknowledge a write/read, which adds round-trip latency.

  • Relaxing to eventual consistency lets a single nearby replica answer immediately, reducing latency.

• Examples:

  • Cassandra is PA/EL: favors availability and low latency, eventual consistency.

  • A fully consistent store is PC/EC: pays latency for correctness even when healthy.

• Takeaway: consistency has a cost during normal operation too, not only during failures.

A quorum is the minimum number of replicas that must acknowledge an operation. With N replicas, requiring R replicas for reads and W for writes, when R + W > N the read and write sets must overlap on at least one node, guaranteeing a read sees the latest write.

• The variables:

  • N: total replicas holding a key.

  • W: replicas that must ack a write before it's considered successful.

  • R: replicas that must respond to a read.

• Strong consistency: R + W > N:

  • Overlap guarantees at least one read replica has the newest write, so reads are current.

  • Example with N=3: W=2, R=2 (sum 4 > 3).

• Eventual consistency: R + W <= N: No guaranteed overlap; reads may return stale data but latency/availability improve. e.g. W=1, R=1.

• Tuning the balance:

  • High W = durable, slower writes; high R = fresher, slower reads.

  • Write-heavy systems often pick low W, high R; read-heavy do the reverse.

• Caveat: quorum overlap ensures freshness only if conflicts are resolved correctly (versioning, last-write-wins, or vector clocks).

Read-your-writes consistency guarantees that once a user has written a value, any subsequent read by that same user will reflect that write (never an older value). It's hard in a distributed system because a follow-up read may land on a replica that hasn't received the write yet.

• The core problem:

  • Writes go to one replica and propagate asynchronously; reads may be load-balanced to a different, lagging replica.

  • So a user can save data and then immediately not see it: confusing and looks like data loss.

• Why it's challenging:

  • Replication lag is variable and unbounded under load or partitions.

  • Stateless load balancers don't know which replica has the latest data for this user.

• How it's typically achieved:

  • Sticky routing: pin a user's session to the replica/primary they wrote to.

  • Read-from-primary for a short window after a write.

  • Track a write timestamp/version per session and only read from replicas caught up to it.

  • Quorum reads (R + W > N) so the read set overlaps the write set.

Monotonic read consistency guarantees that once a client has seen a particular value, it will never subsequently see an older value: reads only move forward in time. It prevents the anomaly of "reading backwards".

• The anomaly it prevents:

  • In an eventually consistent system, replicas lag at different rates.

  • A client reads an updated value from an up-to-date replica, then a later read hits a stale replica and shows the old value: data appears to go back in time.

• What the guarantee provides:

  • Successive reads return that value or a newer one, never an earlier one.

  • It is a per-client (session) guarantee, not global consistency.

• How it's implemented: Pin a client's reads to the same replica, or track a version/timestamp and only read from replicas at least that current.

Single-table design stores multiple entity types (and their relationships) in one table, distinguishing them through carefully constructed partition and sort keys. It's used in key-value/wide-column stores like DynamoDB to fetch related entities together in a single query, avoiding joins the database can't perform.

• How it works:

  • Different entity types share the table, marked by a type attribute and key prefixes (e.g. USER#123, ORDER#456).

  • Related items share a partition key so one query returns them together (item collections).

  • Generic keys (PK/SK) and secondary indexes serve multiple access patterns on the same data.

• Why use it:

  • Fetch a parent and its children in one round trip, with no joins.

  • Fewer round trips and predictable single-digit-ms latency at scale.

  • One set of capacity/throughput to manage instead of many tables.

• Trade-offs:

  • Steep learning curve and opaque data: items look heterogeneous and hard to read raw.

  • Requires knowing access patterns up front; new patterns can be painful to add.

A materialized view is a precomputed, persisted copy of data reorganized to serve a specific query, kept up to date automatically or by your write logic. It lets you store the same data multiple ways so each query reads from a structure built for it.

• What it is:

  • Unlike a relational view (computed on the fly), a NoSQL materialized view is stored on disk and read like a normal table.

  • It typically uses a different partition/primary key than the base table to support a different access path.

• How it supports query-driven design:

  • NoSQL modeling starts from the queries; a view gives you a second (or third) physical layout so each query hits its own optimized structure.

  • Example: a base table keyed by user_id plus a materialized view keyed by email to look users up by email.

• Mechanism:

  • Some databases maintain them automatically (Cassandra MATERIALIZED VIEW); otherwise you write to multiple tables yourself in the application.

  • Trade-off: faster reads at the cost of extra storage and write amplification (every base write updates the views too).

Consistent hashing maps both keys and nodes onto the same circular hash space (a "ring"), and each key is owned by the next node clockwise. Because adding or removing a node only reassigns the keys between it and its neighbor, you move roughly 1/N of the data instead of rehashing everything.

• The ring:

  • Hash the key and walk clockwise to the first node; that node stores the key.

  • Contrast with hash(key) % N, where changing N remaps almost every key.

• Why little data moves:

  • Adding a node: it takes over only the arc of keys between it and its predecessor; other nodes are untouched.

  • Removing a node: its keys shift to the next clockwise node only.

• Virtual nodes: Each physical node is placed at many points on the ring (vnodes) to smooth out uneven distribution and spread a failed node's load across many peers.

• Where it's used: Dynamo-style systems (Cassandra, DynamoDB, Riak) use it for partitioning and elastic scaling.

A hot partition (or hot key) occurs when a disproportionate share of traffic or data lands on a single partition, overwhelming one node while others sit idle. It almost always traces back to a low-cardinality or skewed partition key, and you fix it by choosing a key that spreads load evenly.

• What causes it:

  • Low-cardinality keys (e.g. status with few values) or monotonic keys (timestamps) that funnel writes to one place.

  • A naturally popular item (a celebrity user, a viral product) drawing outsized read traffic.

• How to identify it:

  • Per-partition metrics show one partition's throughput, latency, or throttling far above the rest.

  • Symptoms: throttling/timeouts on some keys while overall cluster utilization looks low.

• How to resolve it:

  • Pick a higher-cardinality partition key that distributes access evenly.

  • Write sharding (salting): append a suffix/bucket to the key (e.g. userId#3) to split a hot key across N partitions, then scatter-gather on read.

  • Use a composite key so traffic spreads across many partition values rather than one.

  • For hot reads, front the key with a cache.

• Trade-off: Salting fixes write hotspots but complicates reads, since you must query all buckets and merge.

Adding or removing nodes requires rebalancing data ownership so each node holds its fair share, and the hard part is doing this while the cluster keeps serving traffic. Modern NoSQL systems handle it through consistent hashing and background streaming of data, so only a fraction of keys move and there's no downtime.

• The core challenge:

  • Naive modulo hashing remaps almost all keys when node count changes, forcing a massive reshuffle.

  • You must keep reads/writes correct while ownership is in flux.

• Consistent hashing minimizes movement:

  • Nodes and keys map onto a hash ring; adding a node only steals a slice from its neighbors, so only ~1/N of keys relocate.

  • Virtual nodes (vnodes) split each physical node into many ring tokens for smoother, faster rebalancing.

• Moving data without downtime:

  • New ownership is computed, then data is streamed in the background while the old owner keeps serving.

  • During transfer, both source and target may receive writes; the coordinator routes accordingly until handoff completes.

  • On removal/decommission, the leaving node streams its ranges to successors before exiting.

• Operational concerns:

  • Streaming adds network/IO load, so rebalancing is throttled to protect live latency.

  • Replication factor must still be satisfied throughout the transition.

The cluster maps every key to a node using a partitioning function (usually a hash ring), and the request is routed to a node that owns the key's token range. Depending on the system, either any node acts as a coordinator that forwards the request, or a smart client computes the target directly.

• Key-to-node mapping:

  • Hash the partition key to a token; consistent hashing determines which node(s) own that token range.

  • Replicas are the next N nodes around the ring.

• Coordinator (peer-to-peer) routing:

  • In masterless systems (Cassandra, Dynamo), any node can receive the request and becomes the coordinator.

  • It looks up the owning replicas, forwards the request, gathers quorum responses, and replies to the client.

• Config/metadata server routing: Some systems use a routing tier or metadata service (e.g. MongoDB's mongos with config servers) that knows the shard map and proxies the request.

• Token-aware / smart clients: The driver caches the cluster's token map (via gossip) and sends the request straight to a replica, avoiding an extra hop.

• Membership awareness: Nodes share ring/topology state through a gossip protocol so routing stays correct as nodes join or leave.

A ledger database is an append-only store that maintains an immutable, cryptographically verifiable history of every change, so you can prove that data has not been tampered with. It solves the problem of trustworthy auditability: instead of bolting on audit tables you can secretly edit, the database itself guarantees the record is complete and unaltered.

• Append-only and immutable: You never overwrite or delete in place; updates add a new version, so the full history is always preserved.

• Cryptographic verification:

  • Entries are chained with hashes (each record's hash depends on the prior one), often into a Merkle tree, producing a digest that proves the chain hasn't been altered.

  • Any tampering changes downstream hashes, so verification fails: this is detectable without trusting an administrator.

• Problem it solves:

  • Regulatory/audit needs (finance, supply chain, healthcare) where you must prove the integrity and complete history of records.

  • Examples: Amazon QLDB; conceptually related to blockchain but centrally owned, not decentralized.

• When NOT to use it: If you don't need verifiable immutability, a regular database with audit logging is simpler and more flexible.

In a multi-leader (or leaderless) setup, the same data can be written concurrently on different nodes, producing conflicting versions that must be reconciled. Last-Write-Wins (LWW) resolves conflicts by picking the write with the latest timestamp, while Vector Clocks track causality so the system can detect which writes are concurrent and preserve both for resolution.

• Last-Write-Wins (LWW):

  • Each write carries a timestamp; on conflict, the highest timestamp wins and the other is discarded.

  • Simple and cheap, but lossy: a concurrent write can be silently dropped, and clock skew across nodes can pick the "wrong" winner.

• Vector Clocks:

  • Each replica maintains a per-node counter; a version's vector summarizes which updates it has seen.

  • Comparing vectors tells you if one write causally descends from another (safe to overwrite) or if they are concurrent (a true conflict).

  • Concurrent versions are kept as siblings and handed to the application (or a CRDT/merge function) to reconcile, so no write is silently lost.

• Choosing between them:

  • LWW fits caches or last-value-wins data where losing a write is acceptable.

  • Vector clocks fit data where every update matters (e.g., a shopping cart) at the cost of complexity and storing multiple versions.