NoSQL Database Models Interview Preparation Guide

Wide-column stores like Apache Cassandra organize data into strict rows defined by composite partition and clustering keys, optimized for massive append-only write throughput and range scans over pre-sorted data. Document databases like MongoDB store hierarchical, semi-structured JSON/BSON documents that allow nested arrays and sub-documents, prioritizing flexible schema iteration and rich secondary indexing. In interviews, you should highlight that wide-column stores demand query-driven denormalization, whereas document databases offer more flexibility for nested entity models while still supporting multi-document ACID transactions.

Graph databases should be chosen when application workloads require deep, multi-hop relationship traversals (such as fraud detection, recommendation engines, or social network pathfinding) where traversal depth is dynamic or unpredictable. While relational databases can execute recursive Common Table Expressions (CTEs), performance degrades exponentially as join depth increases due to relational index lookup overhead. Graph databases utilize index-free adjacency, meaning each node maintains direct physical pointers to adjacent nodes, enabling constant-time traversal performance regardless of total graph scale.

Tunable consistency allows clients to specify the consistency level (e.g., ONE, QUORUM, ALL) for individual read and write operations. The mathematical guarantee for strong consistency relies on the inequality $R + W > N$, where $N$ is the replication factor, $R$ is the number of replicas queried for a read, and $W$ is the number of replicas that must acknowledge a write. If this inequality holds, the read set and write set are guaranteed to overlap by at least one node, preventing stale reads. Setting lower levels like ONE maximizes availability and lowers latency during network partitions at the cost of potential eventual consistency anomalies.

Hot spotting occurs when incoming read or write requests disproportionately target a single partition key, overwhelming the physical node responsible for that token range while other cluster nodes remain idle. This typically happens when using monotonic keys like auto-incrementing integers, daily timestamps, or viral user IDs. Prevention requires careful partition key design, such as applying the 'Bucket Pattern' where a random or hashed suffix (e.g., user_id#bucket_3) is appended to high-frequency keys to distribute load across multiple physical nodes in the consistent hashing ring.

Log-Structured Merge-trees (LSM-trees) optimize for write-heavy workloads by buffering incoming mutations in an in-memory MemTable and appending them sequentially to a disk CommitLog, converting random disk I/O into sequential append operations. Background compaction processes periodically merge immutable SSTable data files. B-Trees, commonly used in relational engines, perform in-place updates on disk pages, which introduces random I/O overhead and lock contention under heavy write concurrency. LSM-trees trade off read performance (requiring Bloom filters and checking multiple SSTables) for unmatched write ingestion throughput.

Wide-column stores do not support efficient server-side joins across tables. Normalizing data into separate tables and executing queries that require joining multiple entities results in multiple network round trips, heavy coordination overhead, and unacceptable query latencies. Instead, wide-column modeling mandates query-driven denormalization—duplicating data across multiple purpose-built tables so that every application query can be satisfied by reading a single partition in a single disk seek.

Tombstones are special markers written to distributed storage when a record is deleted, recording a timestamp to ensure the deletion propagates across replicas rather than the record simply disappearing (which could cause stale data to be resurrected from lagging nodes). If an application performs excessive deletes or overwrites without proper compaction, an accumulation of tombstones forces storage engines to scan through vast numbers of deleted markers during read operations, causing severe read latency spikes and occasional memory exhaustion.

CRDTs are specialized data structures used in distributed systems that can be replicated across multiple nodes where independent, concurrent updates can occur without coordination or locking. Mathematically, they form join-semilattices, ensuring that concurrent mutations are associative, commutative, and idempotent. When replicas synchronize, their states merge deterministically regardless of message delivery order or network latency, guaranteeing eventual convergence without requiring distributed two-phase commit locks.

A local secondary index partitions index entries within the same partition key as the base table, meaning index queries are scoped to a single partition and execute efficiently. A global secondary index maintains index partitions across the entire cluster, allowing ad-hoc queries across all base partitions. However, global secondary indexes require distributed write coordination across cluster nodes during every base table mutation, significantly amplifying write IOPS and increasing coordination latency.

Key-value stores achieve ultra-low latency by storing data primarily in main system memory (RAM) using highly optimized data structures like hash tables, skip lists, or compressed radix trees. By avoiding disk I/O bottlenecks and complex query parsing overhead, they execute lookup and mutation operations in strict O(1) time complexity. Persistence mechanisms like RDB snapshots or AOF append logs run asynchronously in background threads, ensuring durability without blocking high-frequency client request threads.