NoSQL Interview Questions — Hot Partition Took Down Payment

NoSQL databases power some of the most traffic-heavy systems on the planet — think Netflix's viewing history, Twitter's social graph, and Uber's real-time location tracking. Interviewers don't ask about NoSQL to trip you up on syntax. They ask because choosing the wrong database model has sunk real products, and they want to know if you understand the trade-offs well enough to make that call under pressure.

The problem NoSQL solves isn't that SQL is bad. It's that relational databases were designed for a world where data had a known, fixed shape and horizontal scaling wasn't a priority. When your schema changes every sprint, your data is deeply nested, or you need to write to a million users per second across three continents, SQL starts to buckle. NoSQL databases trade some guarantees — like strict ACID transactions — for flexibility and scale.

By the end of this article, you'll be able to explain the four NoSQL data models with real examples, articulate the CAP theorem without reciting a textbook definition, talk confidently about consistency levels and when to sacrifice them, and answer the tricky follow-up questions that expose candidates who just memorized bullet points.

The CAP Theorem: The Heart of Every NoSQL Architectural Choice

In any distributed system, you can only provide two out of three guarantees: Consistency (every read receives the most recent write), Availability (every request receives a response), and Partition Tolerance (the system continues to operate despite network failures).

Because network partitions are an inevitable reality of distributed hardware, you are almost always choosing between CP (Consistency and Partition Tolerance) and AP (Availability and Partition Tolerance). For example, MongoDB defaults to CP—if the primary node goes down, the system stops writes until a new leader is elected to ensure data isn't lost. In contrast, Cassandra is typically AP—it will keep taking writes even if nodes can't talk to each other, resolving conflicts later using 'Last Write Wins'.

Schema Design: From Normalization to Denormalization

In SQL, we normalize to save space. In NoSQL, storage is cheap, so we denormalize to save time. Instead of joining an Orders table with a Users table at query time, we embed the user's name and address directly into the Order document. This means one 'Get' operation retrieves everything needed for the UI, eliminating the performance bottleneck of complex joins.

But don't over-embed. If you embed everything, document size grows unbounded and can exceed MongoDB's 16MB limit. The rule: embed where you always read the embedded data together. Otherwise, reference and read separately. Query patterns drive the schema — not the data.

Consistency Models: From Strong to Eventual — What You Must Choose

NoSQL systems offer a spectrum of consistency levels, not just 'consistent' vs 'inconsistent'. At one end, strong consistency guarantees that every read returns the latest write — same as ACID. At the other, eventual consistency says that if no new writes happen, all replicas will converge to the same value eventually.

Between these endpoints are tunable models: causal consistency (writes that are causally related are seen in order), monotonic reads (once you read a value, you never see an older one), and read-your-writes (you always see your own latest write). DynamoDB lets you request strongly consistent reads per-query at a higher latency cost. Cassandra offers tunable consistency for both reads and writes.

The trap: candidates often say 'I'll use eventual consistency for everything because it's faster.' That fails when the scenario requires, say, a banking transaction. Interviewers want to hear you reason about the cost of consistency — for strong, you pay latency and availability. For weak, you pay complexity and potential staleness.

Indexing Strategies: Making NoSQL Queries Fast Without Losing Writes

NoSQL databases index differently from relational ones. MongoDB supports single-field, compound, multi-key (arrays), text, and geospatial indexes. Cassandra uses a primary key with a partition key and clustering columns — you can only query efficiently by partition key or by clustering columns within a partition. Secondary indexes in Cassandra are notoriously slow for high-cardinality data.

DynamoDB also limits secondary indexes: a Local Secondary Index (LSI) must share the same partition key, while a Global Secondary Index (GSI) can have a different partition key but adds cost and eventually consistent reads.

The key insight: you cannot index 'everything' like in SQL. You must design indexes for your known query patterns. Every extra index slows writes and consumes memory. Interviewers ask this because they've seen production outages caused by runaway secondary indexes in Cassandra.

Sharding and Replication: How NoSQL Scales Horizontally

Sharding splits data across multiple servers (shards) based on a shard key. MongoDB uses a range-based or hashed shard key. Cassandra distributes data automatically using consistent hashing on the partition key. DynamoDB uses a partition key for internal sharding.

The most common production failure: a skewed shard key causes a hot partition — one node handles 90% of traffic while others idle. Interviewers expect you to know how to choose a good shard key: one that distributes writes evenly and doesn't create hot spots.

Replication provides durability and read scalability. MongoDB uses a replica set with a primary and multiple secondaries. Cassandra uses a peer-to-peer model with configurable replication factor and consistency levels. The replication factor directly affects write throughput and data safety — too low and you lose data on node failure, too high and writes slow down.

Conflict Resolution: Last Write Wins, CRDTs, and How Real Systems Handle Chaos

In AP systems like Cassandra and DynamoDB, concurrent writes to the same data can cause conflicts. The simplest strategy is 'Last Write Wins' (LWW) — the write with the latest timestamp wins. But LWW has a dangerous flaw: if two clients write simultaneously, one write is silently discarded. In systems where you cannot lose data, you need more sophisticated resolution: application-level conflict resolution (Amazon Shopping Cart pattern), CRDTs (conflict-free replicated data types), or vector clocks.

Cassandra uses LWW by default but allows you to provide a custom conflict resolution class. DynamoDB's 'conditional writes' let you reject overwrites based on a condition. Riak (now deprecated) used vector clocks. Interviewers love to ask: 'How would you implement a shopping cart that doesn't lose items?' The answer isn't LWW — you need to merge sets (a CRDT).

Frequently Asked Questions