NoSQL Database Interview Questions & Answers

SQL databases excel when you need strong consistency, complex joins, and well-defined schemas. Choose SQL for financial systems, inventory management, or any domain where ACID transactions and referential integrity are critical. The rigid schema enforces data quality and supports complex analytical queries.

NoSQL shines when you need horizontal scaling, schema flexibility, or high write throughput. Use NoSQL for user profiles, product catalogs, real-time analytics, or content management where the data model evolves frequently. NoSQL trades ACID for BASE (Basically Available, Soft state, Eventual consistency) to achieve partition tolerance and availability.

Consider hybrid approaches: use SQL for transactional core data and NoSQL for caching, search, or event streams. The choice often comes down to whether your primary constraint is consistency (SQL) or scalability and flexibility (NoSQL).

The CAP theorem states that a distributed system can guarantee only two of three properties: Consistency (every read receives the most recent write), Availability (every request receives a response), and Partition tolerance (the system works despite network failures). In practice, partition tolerance is unavoidable in distributed systems, so you choose between CP and AP.

MongoDB is CP by default: during a partition, it prioritizes consistency over availability. Replica set elections pause writes until a primary is elected. Cassandra and DynamoDB are AP: they favor availability during partitions. Writes succeed to any node, and conflicts are resolved eventually. Cassandra uses tunable consistency per operation.

Real-world mapping: Banking systems choose CP (correct balance over availability). Social feeds choose AP (show something rather than errors). Understanding these tradeoffs is essential for designing distributed systems.

NoSQL databases fall into four main categories. Document stores like MongoDB store data as JSON-like documents. Use them for content management, catalogs, or when your schema varies per record. Key-value stores like Redis and DynamoDB map keys to values. They excel at caching, session storage, and simple lookups with sub-millisecond latency.

Column-family stores like Cassandra and HBase organize data by column families, optimizing for wide rows and high write throughput. Use them for time-series data, event logs, or analytics. Graph databases like Neo4j store nodes and relationships. They shine for social networks, recommendation engines, fraud detection, and any domain where relationships matter more than the data itself.

Choosing the right type depends on your access patterns: document for flexible schemas, key-value for speed, column-family for writes and analytics, graph for relationships.

Strong consistency guarantees that a read always returns the most recent write. It simplifies application logic but requires coordination across replicas, which can increase latency and reduce availability during partitions.

Eventual consistency allows replicas to diverge temporarily. All replicas will converge to the same state given enough time and no new writes. Variants include read-your-writes (a client sees its own writes immediately), causal consistency (preserves cause-effect order), and session consistency (guarantees within a session).

Cassandra offers tunable consistency: you can require quorum reads and writes for strong consistency, or ONE for availability. DynamoDB uses eventually consistent reads by default but offers strongly consistent reads as an option. Choose based on your tolerance for stale data versus latency and availability requirements.

Embedding stores related data inside a single document. Use it when the relationship is one-to-few, the embedded data is always accessed with the parent, and the embedded data rarely grows unbounded. Example: a user with a fixed set of addresses. Embedding reduces round trips and keeps related data co-located.

Referencing stores IDs that point to separate documents. Use it when you have one-to-many or many-to-many relationships, when the child data is accessed independently, or when the child collection can grow large. Example: blog posts with comments — comments can be queried separately and grow indefinitely.

For e-commerce: embed product variants (size, color) in the product document. Reference orders in a separate collection since they're queried independently and grow over time. The key is matching the pattern to your access patterns.

The aggregation pipeline processes documents through a sequence of stages. Each stage transforms the documents and passes results to the next stage. Common stages include $match (filter documents, like WHERE), $group (aggregate by key, like GROUP BY), $project (reshape fields, like SELECT), $lookup (join with another collection), and $unwind (deconstruct arrays into separate documents).

The pipeline executes as a stream: documents flow through stages one at a time, enabling efficient memory use. You can add indexes to support $match and $sort. The order of stages matters: filter early with $match to reduce documents before expensive $group or $lookup operations.

Practical use: analyze sales by region, compute user engagement metrics, or denormalize data for reporting. The pipeline is more expressive than simple find() and supports complex analytics without moving data to a separate system.

Replication provides high availability via replica sets. Each set has one primary and multiple secondaries. Writes go to the primary and replicate asynchronously. Read preferences control where reads go: primary (default for strong consistency), primaryPreferred, secondary (for read scaling), secondaryPreferred, or nearest (lowest latency). Write concern (w: 1, w: "majority", w: 0) controls when writes are acknowledged.

Sharding distributes data across shards by a shard key. Choose the shard key carefully: it determines data distribution and query routing. A bad key causes hot shards or scatter-gather queries. Range-based keys can create hotspots; hashed keys distribute evenly but prevent range queries. Chunks are the unit of migration; MongoDB balances chunks across shards.

Best practice: use compound shard keys (e.g., {userId: 1, createdAt: 1}) for common query patterns. Avoid high-cardinality monotonic keys that create hotspots.

Redis offers six core data structures. Strings store simple values; use for caching, counters, or session IDs. Lists are ordered sequences; use for queues, activity feeds, or recent items. Sets are unordered unique collections; use for tags, unique visitors, or set operations (intersection, union). Sorted Sets rank members by score; use for leaderboards, priority queues, or time-weighted rankings.

Hashes store field-value maps; use for object caching (user profiles, product data) to avoid serializing entire objects. Streams are append-only logs with consumer groups; use for event sourcing, message queues, or activity logs.

Practical mapping: cache API responses (Strings), rate limiting (Strings with INCR + EXPIRE), leaderboard (Sorted Sets with ZADD/ZREVRANGE), session store (Hashes), real-time feeds (Streams).

Cache-Aside (Lazy Loading) is the most common pattern. The application manages the cache: on a read miss, fetch from DB, populate cache, return data. On writes, update the DB and invalidate (delete) the cache. Pros: cache only holds requested data, simple. Cons: cache miss penalty, possible stale reads if invalidation fails.

Write-Through keeps cache and DB in sync on every write. The cache layer writes to both cache and DB atomically. Reads always hit cache. Pros: strong consistency. Cons: every write has DB latency, unused data may be cached.

Write-Behind (Write-Back) writes to cache first, then asynchronously to DB. Pros: very fast writes, absorbs write bursts. Cons: risk of data loss if cache fails before flush, eventual consistency. Use for high-write, low-criticality data like analytics or click streams.

Single-table design stores multiple entity types in one table, using composite keys (PK + SK) to enable multiple access patterns. The key insight: design for access patterns first, not for normalized entities. Use generic attribute names like PK and SK, and overload them with different key schemes (e.g., USER#123, ORDER#456#789).

Partition key determines physical distribution; sort key enables range queries within a partition. GSIs provide alternate access patterns with different key structures. Avoid hot partitions: ensure partition key has high cardinality and distributes load evenly.

Example: USER#123 as PK with PROFILE as SK for user profile; USER#123 with ORDER#timestamp as SK for user's orders; ORDER#456 as PK with ITEM#789 as SK for order line items. One table, many access patterns.

The partition key determines which node stores the data and how it's distributed. All rows with the same partition key live on the same node. A good partition key has high cardinality to distribute data evenly and matches your query patterns.

Hot partitions occur when one partition receives disproportionate read/write load. Example: using only 'date' as partition key for events creates one partition per day — all writes hit one partition. Solution: add high-cardinality component (e.g., user_id, bucket) to the partition key.

Compound keys: (user_id, timestamp) lets you query a user's events by time range within one partition. Avoid very wide partitions (millions of rows) — they slow reads and create memory pressure. Aim for partitions in the 10MB–100MB range. Use bucketing (e.g., month or week) to bound partition size for time-series data.

MongoDB supports multi-document ACID transactions since 4.0. Use sessions with startTransaction(), perform operations, then commitTransaction() or abortTransaction(). Transactions work across replica sets and sharded clusters. They have performance overhead, so use for operations that truly need atomicity across documents.

DynamoDB offers TransactWriteItems and TransactGetItems for atomic multi-item operations. Up to 100 items per transaction. Use for conditional updates that must succeed or fail together, e.g., transferring inventory between items.

For distributed transactions across services, the saga pattern replaces 2PC. Each service performs a local transaction and publishes an event. If a later step fails, compensating transactions undo previous steps. Saga can be choreographed (events trigger next steps) or orchestrated (central coordinator). Trade-off: eventual consistency and complex failure handling.