NoSQL

NoSQL is a family of non-relational databases optimized for horizontal scale, flexible schemas, and distributed workloads.

• Supports multiple models: document, key-value, wide-column, graph.
• Often favors denormalization and query-driven design.
• Many systems trade strict global consistency for availability/latency at scale.

Use when: scale, flexible schema, high throughput, specialized access patterns. Avoid when: heavy joins + strict relational integrity dominate. Trade-off: flexibility/scalability vs relational guarantees/ad-hoc SQL power. Follow-up: “Is NoSQL schemaless or schema-flexible?”

The core categories are document, key-value, wide-column, and graph.

• Document: MongoDB, Couchbase
• Key-value: Redis, DynamoDB (KV+document)
• Wide-column: Cassandra, HBase, ScyllaDB
• Graph: Neo4j, JanusGraph, Neptune

Use when: choose model by dominant query pattern. Follow-up: “How would you pick one for a recommendation engine?”

SQL emphasizes normalized schema + joins + strong ACID; NoSQL emphasizes model flexibility and horizontal scale.

• SQL: fixed schema, relational constraints, rich joins.
• NoSQL: flexible structures, denormalization, distribution-first.
• Consistency can be tunable/eventual depending on system.

Trade-off: relational rigor vs distribution-first performance. Follow-up: “Can NoSQL still do transactions?”

Choose NoSQL when access patterns are simple but massive-scale, schema evolves quickly, or relationship model isn’t relational-first.

• High write throughput / low-latency key access.
• Evolving payloads, event/time-series, graph traversals.
• Multi-region/high-availability requirements.

Avoid when: complex cross-entity transactional workflows + heavy joins are core. Follow-up: “Give a concrete workload where SQL is better.”

Replicas may temporarily return stale data, but converge if no new writes occur.

• Common in AP/tunable distributed systems.
• Improves availability/latency.
• Requires app tolerance for stale reads/conflicts.

Follow-up: “How to provide read-your-own-writes?”

Reads always return the latest committed write.

• Requires tighter replica coordination.
• Raises latency and can reduce availability under failure.

Use when: correctness > latency/availability (e.g., critical balances). Follow-up: “How does this relate to quorum settings?”

During a network partition, a distributed system must choose stronger consistency or higher availability.

• P (partition tolerance) is mandatory in real distributed systems.
• So practical choice under partition is CP vs AP.
• Outside partition, PACELC explains latency/consistency trade-offs.

Follow-up: “Why is CAP often misunderstood in interviews?”

BASE is a distributed-systems mindset prioritizing availability and eventual convergence over strict ACID everywhere.

• Basically Available
• Soft state
• Eventual consistency

Follow-up: “When is BASE unacceptable?”

Sharding partitions data across nodes by a partition/shard key so each node stores only part of the dataset.

• Enables horizontal scale for storage and throughput.
• Key design determines balance and performance.

Risk: hot partitions from skewed keys. Follow-up: “How do you detect and fix hotspots?”

Replication keeps multiple copies of data on different nodes for availability and durability.

• Improves fault tolerance.
• Can also scale reads.
• Sync vs async replication affects consistency/latency.

Follow-up: “What’s replication lag and why it matters?”

Sharding scales capacity/performance; replication scales resilience and availability.

• Sharding = different data chunks on different nodes.
• Replication = same data copied to multiple nodes.
• Most production systems combine both.

Follow-up: “Can replication alone solve write scaling?”

Yes—single-record atomicity is common, and many modern NoSQL systems also support multi-record ACID transactions.

• Stronger guarantees usually increase overhead.
• Model to keep hot paths atomic within one partition/document when possible.

Follow-up: “Why avoid distributed transactions in hot paths?”

Denormalization duplicates data to serve reads in fewer operations, avoiding expensive joins.

• Query-driven modeling.
• Faster read paths.
• Consistency management shifts to app/pipelines.

Trade-off: read speed vs duplication/update complexity. Follow-up: “How keep duplicates consistent?”

Partition key decides data placement; sort/clustering key orders records within that partition.

• Enables efficient range queries per partition.
• Core pattern in DynamoDB/Cassandra-like models.

Follow-up: “What makes a good partition key?”

A hot partition receives disproportionate traffic, bottlenecking one node/partition.

• Causes latency spikes/throttling.
• Usually due to low-cardinality or time-skewed keys.

Mitigation: write sharding, better keys, bucketing, caching. Follow-up: “How would you redesign a timestamp-only key?”

A document DB stores self-contained records (usually JSON/BSON) with flexible structure.

• Nested objects/arrays are first-class.
• Not all documents must share identical fields.

Use when: hierarchical app payloads with evolving schema. Follow-up: “When embed vs reference?”

A key-value store maps unique keys to values and is optimized for very fast key-based access.

• Extremely low-latency gets/sets.
• Limited secondary querying unless additional indexing features exist.

Use when: cache, sessions, counters, simple lookups. Follow-up: “When does KV stop being enough?”

Wide-column stores organize data by partitioned rows with flexible columns, optimized for huge scale and write-heavy predictable queries.

• Access pattern must align with primary key.
• Great for time-series/event workloads.

Follow-up: “Why ‘one table per query pattern’ in Cassandra?”

Graph DBs model nodes and relationships directly, making multi-hop relationship traversal efficient.

• Best for path/traversal-heavy queries.
• Social, fraud, recommendations, knowledge graphs.

Follow-up: “Why graph beats SQL on deep traversals?”

Secondary indexes speed non-primary-key queries, but add write overhead and storage cost.

• More indexes can hurt write throughput.
• Index choice must reflect real query frequency.

Follow-up: “How decide if an index is worth it?”

Not truly schemaless—better described as schema-flexible.

• DB may enforce less, but application still depends on schema expectations.
• Versioning/validation remain important.

Follow-up: “How do you run schema migrations safely?”

Model data starting from required read/write access patterns, not from normalized entities first.

• List top queries first.
• Shape records so common queries are single/few operations.

Follow-up: “What happens if access patterns change later?”

Embed when data is read together and bounded; reference when relationships are large/shared/unbounded.

• Embed: fewer reads, atomic parent updates.
• Reference: flexible growth, independent querying.

Follow-up: “How would you model comments for viral posts?”

TTL auto-expires records after a configured lifetime.

• Great for sessions, cache entries, ephemeral data.
• Supported in Redis/DynamoDB/Cassandra/MongoDB (via TTL index) with model-specific behavior.

Follow-up: “What pitfalls exist with TTL-based deletes?”

Query is targeted and efficient by key; Scan reads everything and is expensive.

• Query uses partition key (+ optional sort key/index conditions).
• Scan should be avoided in hot production paths.

Follow-up: “How redesign to replace a Scan?”

Redis is an in-memory data store for low-latency cache, sessions, counters, pub/sub, and stream pipelines.

• Rich structures: strings, hashes, sets, zsets, streams.
• Commonly used as a performance layer.

Follow-up: “How do you handle cache stampede?”

Many clients miss the same expired hot key simultaneously and overload the backing database.

• Mitigate with single-flight locking/request coalescing.
• Add TTL jitter, early refresh, background warming.

Follow-up: “What would you implement first and why?”

Cassandra lets you choose consistency level per read/write (ONE, QUORUM, ALL, etc.) to balance latency/availability/consistency.

• With RF=N, stronger consistency needs more acknowledgments.
• Common practical setting in multi-DC: LOCAL_QUORUM.

Follow-up: “Explain R + W > N intuition.”

LSM-tree is a write-optimized storage design: write to memory, flush immutable files, compact in background.

• Very write-friendly.
• Compaction introduces read/write/space amplification trade-offs.

Follow-up: “How does compaction strategy affect latency?”

Typical anti-patterns are SQL-style normalization everywhere, bad partition keys, unbounded collections, and ignoring consistency semantics.

• Also: heavy scans in hot paths, no schema versioning, no migration plan.

Follow-up: “How would you audit an existing schema for these?”

Schema-on-write enforces structure at write time; schema-on-read interprets structure at read time.

• SQL commonly schema-on-write.
• Many NoSQL systems are schema-flexible (schema-on-read leaning).

Trade-off: flexibility vs stronger upfront guarantees. Follow-up: “How do you prevent data quality drift?”

Vertical scaling adds resources to one node; horizontal scaling adds more nodes and distributes load.

• NoSQL systems typically optimize for horizontal growth.

Follow-up: “What challenges appear with horizontal scale?”

CP-leaning systems prioritize consistency under partition; AP-leaning systems prioritize availability with eventual convergence.

• CP-leaning examples: ZooKeeper, HBase, many majority-write/read configs.
• AP-leaning examples: Cassandra/Dynamo-style defaults.

Note: many systems are tunable by configuration. Follow-up: “How does workload decide the better side?”

These are logical containers, but names differ by system.

• Collection (MongoDB)
• Table (Cassandra, DynamoDB)
• Keyspace (Cassandra namespace)
• Database (MongoDB namespace)

Follow-up: “What’s the practical modeling impact?”

Primary key uniquely identifies a record and often controls physical access path.

• KV/document: usually one key.
• Wide-column: often composite (partition + clustering/sort).

Follow-up: “Why is key design more critical in NoSQL?”

BSON is Binary JSON used by MongoDB, adding typed values and compact binary encoding.

• Supports ObjectId, Date, Decimal128, Binary, etc.

Follow-up: “Any implication for interoperability?”

ObjectId is MongoDB’s default _id, a 12-byte identifier that is roughly time-sortable.

• Includes timestamp and uniqueness components.

Follow-up: “When would you avoid ObjectId?”

Polyglot persistence means using multiple databases in one system, each chosen for a specific workload.

• Example: Redis cache + MongoDB app store + Neo4j graph use case.

Trade-off: better fit/perf vs higher operational complexity. Follow-up: “How keep data consistent across stores?”

You gain scalability/flexibility/performance patterns, but you pay in modeling complexity and consistency management.

• Pros: scale, availability, adaptable schema, specialized models.
• Cons: denormalization overhead, fewer joins, duplication sync.

Follow-up: “What team skills are needed to succeed?”

In NoSQL, physical layout and keys determine performance, so schema must be built from real query paths.

• “One query = one efficient access path” goal.

Follow-up: “How do you validate patterns before production?”

Embed for small bounded child sets; reference when child count is large/unbounded.

• Few children -> embedded array.
• Many/unbounded -> separate collection + parent reference + pagination.

Follow-up: “How detect when embedded array becomes a problem?”

Use references/edge tables/duplicated projections based on dominant query direction.

• Arrays of refs for small sets.
• Join/edge collection for scalable many-to-many.

Follow-up: “How avoid consistency drift?”

Keep common-case documents small/fast, and isolate rare oversized records into separate structure.

• Optimizes p95/p99 for the majority.

Follow-up: “How choose outlier threshold?”

Group many small events into time buckets to reduce document count and index overhead.

• Common for telemetry/time-series ingestion.

Follow-up: “How select bucket width?”

Store hot subset inline (e.g., latest 10 items) and keep full history elsewhere.

• Fast frequent reads, bounded document size.

Follow-up: “How keep subset + full history consistent?”

Precompute aggregates on write to accelerate reads.

• Example: maintain counters/totals instead of runtime recompute.

Trade-off: write complexity for read speed. Follow-up: “How recover from drift in computed values?”

Copy a few frequently read fields from related entity into main record to avoid extra lookups.

• Keep only minimal duplicated fields.

Follow-up: “Which fields are safe to duplicate?”

Add schema_version field so readers can handle multiple versions during migration.

• Enables rolling upgrades/backward compatibility.

Follow-up: “Lazy migrate vs batch migrate?”

Prefer backward-compatible readers, versioned documents, then migrate lazily or in batches.

• Options: lazy on read/write, background backfill, dual-write transition.

Follow-up: “How would you validate migration correctness?”

Good partition keys are high-cardinality, traffic-distributing, and aligned to primary query path.

• Avoid skew and monotonic hotspots.

Follow-up: “Give an example of a bad key and fix it.”

Use better keying, write sharding, time bucketing, and caching to spread load.

• Add random suffix or hashed component where acceptable.

Follow-up: “How do you query after write sharding?”

Storage is often cheaper than cross-node joins/latency; duplication optimizes query latency.

• But consistency workflows become mandatory.

Follow-up: “What consistency model makes this practical?”

Use event-driven propagation (CDC/streams), idempotent updaters, and reconciliation jobs.

• Avoid ad hoc dual writes.

Follow-up: “How detect missed updates?”

Model multiple entity types in one table using PK/SK patterns to serve known access paths efficiently.

• Reduces round trips and improves locality.
• Harder to model and evolve.

Follow-up: “When would you reject single-table design?”

Excellent performance/cost for known patterns, but steeper learning curve and less ad hoc flexibility. Follow-up: “How document and test key patterns for a team?”

Use graph DB for deep traversal-heavy queries; document patterns (materialized path/ancestors) for simpler hierarchy access. Follow-up: “When does hierarchy depth force graph adoption?”

Store full hierarchy path string to allow prefix subtree queries.

• Fast subtree lookup.
• Moving nodes requires rewriting descendant paths.

Follow-up: “How reduce rewrite cost on frequent moves?”

Bucket by time, key by entity+time, use TTL retention, and pre-aggregate for dashboards. Follow-up: “When choose dedicated TSDB instead?”

Use insertOne for single docs, insertMany for bulk inserts.

db.users.insertOne({ name: "Ada", age: 36, roles: ["admin"] });
db.users.insertMany([{ name: "Alan" }, { name: "Grace" }]);

Follow-up: “Ordered vs unordered bulk insert behavior?”

Use find for result sets and findOne for a single matching document.

db.users.find({ age: { $gte: 30 } });
db.users.findOne({ name: "Ada" });

Follow-up: “How ensure this query uses an index?”

Core operators include comparison, logical, element, and array operators.

• Comparison: $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin
• Logical: $and, $or, $not, $nor
• Element: $exists, $type
• Array: $all, $elemMatch, $size

Follow-up: “When does $elemMatch matter?”

updateOne updates first match; updateMany updates all matches.

db.users.updateOne({ name: "Ada" }, { $set: { age: 37 } });
db.users.updateMany({ active: false }, { $set: { archived: true } });

Follow-up: “How prevent accidental mass updates?”

Frequently used operators are $set, $inc, $unset, and array modifiers. $set, $unset, $inc, $mul, $rename, $min, $max, $push, $pull, $addToSet, $pop, $currentDate Follow-up: “Difference between $push and $addToSet?”

Upsert updates if matched, otherwise inserts a new document.

db.counters.updateOne(
  { _id: "page" },
  { $inc: { views: 1 } },
  { upsert: true }
);

Follow-up: “How to make upserts idempotent safely?”

Use dot notation for nested document paths.

db.users.find({ "address.city": "Sofia" });

Follow-up: “Indexing nested fields?”

Arrays can be matched by value, all-values, or element criteria with $elemMatch.

db.posts.find({ tags: "mongodb" });
db.posts.find({ tags: { $all: ["db", "nosql"] } });
db.orders.find({ items: { $elemMatch: { qty: { $gt: 5 } } } });

Follow-up: “How do multikey indexes help here?”

Projection returns only needed fields, reducing payload.

db.users.find({}, { name: 1, email: 1, _id: 0 });

Follow-up: “When can projection become a covered query?”

A stage-based data processing flow for filtering, grouping, transforming, joining, and analytics.

• Typical: $match -> $group -> $project -> $sort

Follow-up: “Why should $match be early?”

Group paid orders by customer and rank totals.

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $group: { _id: "$customerId", total: { $sum: "$amount" } } },
  { $sort: { total: -1 } },
  { $limit: 10 }
]);

Follow-up: “What index supports this best?”

$lookup performs a left outer join with another collection.

db.orders.aggregate([
  {
    $lookup: {
      from: "customers",
      localField: "custId",
      foreignField: "_id",
      as: "customer"
    }
  }
]);

Follow-up: “When should you avoid $lookup at scale?”

Early filtering shrinks downstream work and improves chance of index usage. Follow-up: “Any cases where it cannot be first?”

$unwind expands array elements into separate pipeline documents.

• Useful before grouping/filtering by array entries.

Follow-up: “How handle documents with empty arrays?”

find() is for simple filter/projection; aggregate() for multi-stage transforms, grouping, joins, computed fields. Follow-up: “When does a simple find outperform pipeline?”

Create indexes for frequent query/sort patterns; unique for constraints.

db.users.createIndex({ email: 1 }, { unique: true });
db.posts.createIndex({ author: 1, createdAt: -1 });

Follow-up: “How many indexes are too many?”

Compound index obeys prefix rule, so field order must match common query prefixes.

• {a:1,b:1} supports a and a+b efficiently, not b alone.

Follow-up: “How does sort direction interact with compound index?”

Covered query is answered from index alone without fetching base documents.

• Filtered + returned fields must be in index.

Follow-up: “How verify coverage with explain?”

Use explain("executionStats") to inspect plan quality and scanned docs.

db.users.find({ email: "a@b.com" }).explain("executionStats");

• Prefer IXSCAN over COLLSCAN
• Watch examined vs returned ratio

Follow-up: “What ratio signals trouble?”

Multikey indexes index array elements, enabling efficient array queries. Follow-up: “Any limits with multikey + compound indexes?”

TTL index auto-deletes documents after expiry based on indexed date field.

db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 });

Follow-up: “Is expiration immediate at exact second?”

Text indexes support basic full-text queries; advanced relevance/features usually need Atlas Search/OpenSearch.

db.articles.createIndex({ body: "text" });
db.articles.find({ $text: { $search: "nosql database" } });

Follow-up: “When should you move to dedicated search?”

Sparse indexes include docs with field present; partial indexes include docs matching a filter.

• Both reduce index size/write cost for targeted workloads.

Follow-up: “Which is safer for business rules?”

Single-document writes are atomic by default; multi-document ACID transactions exist but add overhead. Follow-up: “How to avoid needing multi-doc tx in hot paths?”

Write concern controls durability acknowledgments; read concern controls consistency guarantees for reads.

• Write: w, j
• Read: local, majority, linearizable

Follow-up: “What’s a practical default for many apps?”

Read preference selects where reads go (primary/secondary variants), trading freshness for scale/locality.

• Secondary reads can be stale.

Follow-up: “How to implement read-your-own-writes?”

WiredTiger is MongoDB’s default engine with document-level concurrency, compression, and snapshot reads. Follow-up: “Why does this matter for performance?”

GridFS stores files larger than 16 MB as chunks across special collections.

• fs.files and fs.chunks

Follow-up: “When prefer object storage instead?”

Shard key partitions data; mongos routes requests; config servers store metadata; balancer redistributes chunks. Follow-up: “How choose shard key to avoid hotspots?”

Change streams provide real-time insert/update/delete events from oplog for event-driven integrations. Follow-up: “At-least-once handling patterns?”

Redis is an in-memory data store used for ultra-low-latency caching, sessions, counters, queues, and streaming. Follow-up: “What happens on restart without persistence?”

Redis supports strings, hashes, lists, sets, sorted sets, streams, and more specialized structures. Follow-up: “Which structure for leaderboard and why?”

Core commands are SET/GET/INCR with optional expirations and multi-set operations.

SET key value
GET key
INCR counter
SETEX key 60 value
MSET k1 v1 k2 v2

Follow-up: “SETEX vs SET EX?”

TTL can be set explicitly and expires via lazy + active expiration cycles.

• EXPIRE key seconds
• SET key value EX seconds
• TTL key to inspect remaining time

Follow-up: “How does TTL jitter help?”

When max memory is hit, eviction behavior depends on configured policy (LRU/LFU/random/volatile/allkeys/noeviction). Follow-up: “Which policy for cache-heavy workload?”

LRU evicts least recently used; LFU evicts least frequently used.

• LFU often better when long-term hotness matters.

Follow-up: “Any downside of LFU?”

RDB snapshots are compact/fast; AOF is more durable but heavier; many setups combine both. Follow-up: “How choose RDB/AOF strategy for recovery goals?”

ZSet stores unique members with ordered numeric score, ideal for ranking/priority queries.

ZADD leaderboard 100 "ada"
ZREVRANGE leaderboard 0 9 WITHSCORES

Follow-up: “How implement paginated leaderboard?”

Pub/Sub is real-time but not durable—offline consumers miss messages.

• Use Streams for durable delivery.

Follow-up: “When is Pub/Sub still the right choice?”

Streams provide durable append-only messaging with IDs, consumer groups, and acknowledgments. Follow-up: “How handle duplicate processing?”

Common patterns are cache-aside, write-through, write-behind, and read-through.

• Most common in apps: cache-aside.

Follow-up: “Which pattern minimizes stale data risk?”

Use SET lock:key token NX PX ttl to acquire and token-verified atomic release (often Lua) to avoid releasing others’ locks.

SET lock:key <token> NX PX 30000

Follow-up: “What are lock failure modes in partitions?”

Redis Cluster shards keys across 16384 hash slots distributed among primaries (with replicas for failover). Follow-up: “How do multi-key commands behave across slots?”

Command execution is mostly single-threaded; modern Redis uses extra threads for I/O/background work. Follow-up: “Why can single-threaded command execution still be fast?”

DynamoDB is AWS managed NoSQL (KV+document) with low-latency access and automatic scaling. Follow-up: “Provisioned vs on-demand mode?”

Partition key controls placement; sort key orders items sharing partition key and enables range queries. Follow-up: “How model one-to-many with PK/SK?”

Query is key-based and efficient; Scan reads full table/index and is costly. Follow-up: “How to eliminate production scans?”

GSI supports alternate partition/sort keys and separate throughput; LSI shares base partition key and must be defined at table creation.

• GSI reads are eventual.
• LSI can be strongly consistent.

Follow-up: “When choose GSI over table redesign?”

Table/LSI reads can be eventual or strong; GSI reads are eventual.

• Strong consistency costs more latency/throughput.

Follow-up: “Where is strong read actually needed?”

Cassandra is a masterless distributed wide-column DB built for high availability, linear scale, and write-heavy workloads. Follow-up: “Why no single point of failure?”

Table primary key = partition key + clustering columns; partition controls placement, clustering controls in-partition order. Follow-up: “How does this affect query design?”

CQL is SQL-like syntax for Cassandra, but efficient queries must align with partition key design (no arbitrary joins). Follow-up: “Why does ALLOW FILTERING get warned against?”

Cassandra is fast when reads target known partition paths, so schema is built from access patterns first. Follow-up: “Why one table per major query pattern?”

Partition keys hash to token ranges on a ring; vnodes split ownership for better balancing and recovery. Follow-up: “How do vnodes help rebalance?”

RF is number of replicas per partition; higher RF improves resilience but increases storage/network cost. Follow-up: “Typical RF in production and why?”

Set consistency level per operation (ONE/QUORUM/ALL/LOCAL_QUORUM) to balance consistency and latency. Follow-up: “Explain read-after-write with quorum intuition.”

QUORUM is majority acknowledgments: floor(RF/2)+1.

• LOCAL_QUORUM usually preferred in multi-DC for latency control.

Follow-up: “QUORUM vs LOCAL_QUORUM impact?”

Write to commit log + memtable, then flush to immutable SSTables; no read-before-write needed. Follow-up: “How does this design enable high write throughput?”

Background merge of SSTables to remove obsolete data/tombstones and improve read efficiency.

• Strategies: STCS, LCS, TWCS.

Follow-up: “Which strategy fits time-series?”

Tombstone is a delete marker retained until compaction after grace period.

• Excess tombstones degrade reads.

Follow-up: “How to avoid tombstone-heavy queries?”

Frequent deletes create tombstone accumulation, increasing read cost until compaction. Follow-up: “Modeling alternatives to frequent deletes?”

On reads, Cassandra can detect replica mismatch and repair stale replicas. Follow-up: “How does this differ from anti-entropy repair?”

If replica is down, coordinator stores hints and replays later to aid convergence. Follow-up: “What if outage lasts too long?”

Conflict resolution picks highest timestamp, so clock skew can cause unexpected overwrites. Follow-up: “How mitigate clock-skew risk?”

HBase is more CP-leaning/strong-consistency in Hadoop ecosystem; Cassandra is AP-leaning/masterless with strong multi-DC resilience. Follow-up: “Which for globally distributed always-on writes?”

Column family is standard table grouping; super columns are legacy/deprecated concept. Follow-up: “What modern pattern replaces super columns?”

Supports set, list, map, UDT; use for small bounded collections. Follow-up: “When to model as separate rows instead?”

Materialized views maintain alternate primary-key query shape automatically but add operational/consistency complexity. Follow-up: “Safer alternative in critical workloads?”

Secondary indexes can trigger scatter-gather and poor scale; query-specific tables are often better. Follow-up: “When can SAI help?”

Data is nodes + directed relationships, both with properties, enabling direct relationship-centric queries. Follow-up: “Why is relationship first-class important?”

Cypher is declarative graph query language using pattern matching.

MATCH (a:Person)-[:FRIEND]->(b:Person)
WHERE a.name = 'Ada'
RETURN b.name;

Follow-up: “How do indexes help Cypher patterns?”

Use CREATE (or MERGE) to add nodes and edges with labels/properties.

CREATE (a:Person {name: 'Ada'})
CREATE (b:Person {name: 'Alan'})
CREATE (a)-[:FRIEND {since: 2020}]->(b);

Follow-up: “How prevent duplicates?”

Graph DBs excel when multi-hop relationships are core: recommendations, fraud, social, topology, knowledge graphs. Follow-up: “Where graph DB is overkill?”

Graph traversal follows edges directly, while relational multi-hop needs repeated joins that grow expensive. Follow-up: “At what depth do joins become painful?”

Nodes directly reference connected nodes/edges, enabling efficient hop-by-hop traversal. Follow-up: “Does this remove need for indexes entirely?”

Use shortestPath over a variable-length relationship pattern.

MATCH p = shortestPath(
  (a:Person {name:'Ada'})-[:KNOWS*]-(b:Person {name:'Grace'})
)
RETURN p;

Follow-up: “How constrain path to avoid explosion?”

Patterns like [:KNOWS*1..3] traverse bounded hops. Follow-up: “Why bound hop count?”

Property graph is traversal-centric with rich properties; RDF is triple/semantic-web model with SPARQL and URI semantics. Follow-up: “Which is better for ontology-heavy data?”

MERGE matches existing pattern or creates it if missing—useful for idempotent upserts. Follow-up: “Any race conditions with MERGE?”

Graph partitioning is difficult due to cross-partition traversals; scale via replicas, caching, locality-aware partitioning, or distributed engines. Follow-up: “How identify community boundaries for partitioning?”

Graph traversal naturally models similarity/neighborhood patterns for recommendations. Follow-up: “How combine graph features with ML ranking?”

Neo4j supports ACID transactions, useful when relationship integrity is business-critical. Follow-up: “What’s the performance trade-off?”

Neo4j GDS runs in-memory graph algorithms (PageRank, community detection, similarity) for analytics/ML features. Follow-up: “When to use projected graph vs transactional graph?”

Avoid graph DB for simple key lookups, flat aggregations, or ultra-write-heavy non-relational-traversal workloads. Follow-up: “What would you pick instead?”

Majority-based reads/writes can provide strong visibility guarantees when quorums overlap. Follow-up: “How does overlap guarantee freshness?”

If read and write replica sets overlap, reads are more likely to include latest committed write.

• N: replicas, W: write acks, R: read replicas consulted.

Follow-up: “Why still not perfect under clock/repair delays?”

Vector clocks track causality across nodes to detect concurrent updates rather than blindly overwrite. Follow-up: “How is conflict resolved once detected?”

Conflict is concurrent divergent updates; resolve via LWW, merge logic, vector-clock sibling reconciliation, or CRDTs. Follow-up: “Which strategy for user profile edits?”

CRDTs are data types that converge deterministically after concurrent updates without coordination. Follow-up: “Where do CRDTs shine in practice?”

Dynamo popularized consistent hashing, vector clocks, quorums, hinted handoff, and gossip patterns in modern distributed stores. Follow-up: “Which systems adopted these ideas?”

Maps nodes/keys onto a ring so node changes remap only a subset of keys, easing rebalance. Follow-up: “Why add virtual nodes on top?”

Vnodes split each physical node into many token ranges for better load balance and smoother scaling/recovery. Follow-up: “Any operational downside of too many vnodes?”

Nodes periodically exchange cluster-state updates peer-to-peer, spreading membership/failure info without central coordinator. Follow-up: “How does gossip tolerate node failures?”

Merkle trees hash data ranges so replicas can compare hashes and sync only differing ranges efficiently. Follow-up: “Where is this used in repair workflows?”

Background reconciliation process repairs replica divergence to restore long-term consistency. Follow-up: “How often should repair run?”

Session guarantee that a client observes its own previous writes.

• Often implemented by session stickiness or read routing.

Follow-up: “How provide this with eventual-consistent replicas?”

Once a client sees a newer value, it should never later see an older one. Follow-up: “How to enforce across regions?”

Operations with cause-effect relation are observed in order; unrelated concurrent ops may vary in order. Follow-up: “Difference vs strong consistency?”

Beyond CAP during partitions, PACELC says in normal operation systems still trade latency vs consistency. Follow-up: “Give AP/EL or CP/EC style examples.”

Write-ahead/commit log durably records updates before applying to main storage, enabling recovery. Follow-up: “How is commit log different from replication log?”

LSM favors write throughput via memtable + immutable SSTables + compaction. Follow-up: “How does this impact read path?”

B-tree favors in-place read patterns; LSM favors write-heavy workloads but needs compaction and may raise read amplification. Follow-up: “When is B-tree a better fit?”

Bloom filters quickly test “definitely not present” with possible false positives, reducing unnecessary disk lookups. Follow-up: “Why no false negatives?”

Extra physical writes beyond logical writes, often due to compaction/rewrites. Follow-up: “How monitor and reduce it?”

Extra storage reads required for one logical read (e.g., checking multiple SSTables/indexes). Follow-up: “How compaction affects read amp?”

Additional disk usage beyond logical dataset due to tombstones/old versions/compaction overlap. Follow-up: “How can retention policy reduce this?”

Sync waits for replica acks (stronger consistency, higher latency); async acks early (lower latency, temporary data-loss/staleness window). Follow-up: “Which for cross-region writes?”

Partition causes multiple nodes to act as leaders and accept conflicting writes.

• Prevent with quorum, fencing, robust election.

Follow-up: “How detect and recover safely?”

Consensus protocols elect one leader/coordinator to serialize coordination tasks.

• Common algorithms: Raft/Paxos variants.

Follow-up: “What happens on leader failover?”

Both solve consensus; Raft is generally easier to reason about, Paxos is foundational but harder to implement correctly. Follow-up: “Why does understandability matter operationally?”

Use snapshots/logical dumps/PITR based on RPO/RTO, and always test restores regularly. Follow-up: “How often should restore drills run?”

mongodump is logical/portable but slower; volume snapshots are fast for large data but infra-coupled. Follow-up: “Which for multi-terabyte clusters?”

Track p95/p99 latency, throughput, errors, replication lag, resource usage, compaction/GC, and hotspot indicators. Follow-up: “Which 3 alerts would you start with?”

Lag is delay between primary write and replica visibility, causing stale reads and failover risk window. Follow-up: “How reduce lag under burst traffic?”

Enforce auth/RBAC, TLS, encryption at rest, network isolation, least privilege, audit logging, and safe defaults. Follow-up: “Most common misconfiguration in practice?”

Unsafely embedding user input in query objects/operators can alter query logic.

• Validate input strictly.
• Use safe query construction.
• Avoid dangerous script/eval features.

Follow-up: “Show a vulnerable vs safe pattern.”

Use dual-write + backfill + verification + cutover + retirement, with schema versioning and rollback plan. Follow-up: “How would you verify no data loss?”

Change Data Capture streams data changes to downstream systems for search, analytics, cache sync, and event workflows. Follow-up: “How do you guarantee ordering/at-least-once handling?”

Keep primary DB as source of truth; sync changes to search index via CDC for eventual-consistent search views. Follow-up: “How handle reindex/backfill?”

Lambda uses separate batch + streaming paths; Kappa uses one stream pipeline and replay for recomputation. Follow-up: “Which is simpler to operate and why?”

Keep data near compute/users (node/DC/region) to reduce latency and cross-network costs. Follow-up: “How does locality affect partition design?”

Active-passive is simpler consistency-wise; active-active improves availability but needs conflict resolution strategy. Follow-up: “When is active-active worth complexity?”

NoSQL primaries usually serve OLTP; OLAP is often moved to warehouses/search/columnar systems via ETL/CDC. Follow-up: “Why not run heavy analytics on primary cluster?”

Idempotent writes produce same final state on retries, critical for distributed retries and at-least-once systems. Follow-up: “How design idempotency key?”

Write succeeds only if current state matches expected condition (version/existence check), preventing lost updates. Follow-up: “Compare with pessimistic locking.”

Use atomic increments; shard counters for extreme throughput to avoid hotspots. Follow-up: “How read sharded counter efficiently?”

Writing to two systems independently can leave inconsistent state on partial failure.

• Prefer outbox/CDC over naive dual writes.

Follow-up: “Give failure scenario and mitigation.”

Persist business change + outbox event atomically, then relay publishes events asynchronously. Follow-up: “How ensure relay is reliable and idempotent?”

Apps must tolerate stale reads, retries, conflict handling, and communicate pending state clearly in UX. Follow-up: “How do you design UX for eventual consistency?”

Choose based on dominant access pattern:

• document: flexible nested records
• key-value: ultra-fast key access/cache
• wide-column: massive write-heavy predictable queries
• graph: deep relationship traversal

Follow-up: “Can one product combine multiple models?”

One platform can support multiple models to reduce operational overhead, but may be weaker than best-of-breed specialized engines in edge cases. Follow-up: “When choose polyglot over multi-model?”

Benchmark with realistic read/write mix, key distribution, concurrency, and failure scenarios; focus on p95/p99, not averages.

• YCSB is a common baseline.

Follow-up: “How avoid benchmark that lies?”

Boundaries are blurring: NoSQL adds stronger transactions/querying; NewSQL adds distributed scale—both moving toward flexible distributed data platforms. Follow-up: “How would this affect technology choice in 3 years?”