NoSQL Databases

Course: System Design — Zero to Hero
Level: Beginner → Advanced
Phase: Database Fundamentals
Status: Complete

1. What You Will Learn#

In the previous chapters, we studied database fundamentals and SQL databases in depth.

Now we move into NoSQL databases.

You will learn:

• What NoSQL means
• Why NoSQL databases emerged
• Why relational databases are not always the best fit
• The major NoSQL data models
• Document databases
• Key-value databases
• Wide-column databases
• Graph databases
• Schema flexibility
• Access-pattern-first data modeling
• Denormalization
• Embedding vs referencing
• Partitioning
• Sharding
• Replication
• Consistency models
• Eventual consistency
• Quorum concepts
• CAP theorem preview
• Hot partitions
• Secondary indexes
• TTL
• NoSQL transactions
• SQL vs NoSQL
• Polyglot persistence
• Real-world database selection
• Common mistakes
• Interview questions
• Practical exercises
• A NoSQL mini project

The most important lesson is:

NoSQL is not one database technology. It is a family of database models designed around different workloads and scalability requirements.

2. What Does NoSQL Mean?#

Historically, "NoSQL" was often interpreted as:

Not Only SQL.

Today, NoSQL generally refers to database systems that do not primarily use the traditional relational/table model.

NoSQL systems include several different families:

NoSQL
 |
 +-- Document
 |
 +-- Key-Value
 |
 +-- Wide-Column
 |
 +-- Graph

These systems can have very different:

• data models
• query languages
• consistency guarantees
• scaling strategies
• indexing mechanisms
• transaction capabilities

Therefore:

Saying "we use NoSQL" is not enough information.

You should ask:

Which NoSQL data model and why?

3. Why Did NoSQL Databases Become Popular?#

Relational databases are extremely capable.

But some applications operate at very large scale or have workloads that are naturally represented differently.

Imagine:

Billions of records
Millions of requests/sec
Global traffic
Massive write volume
Flexible document structures
Distributed infrastructure

A traditional relational design may become difficult or expensive to scale for certain workloads.

NoSQL systems were developed and adopted to address different classes of these problems.

Typical goals can include:

• horizontal scalability
• high write throughput
• flexible schemas
• predictable access patterns
• distributed operation
• low-latency key-based access
• large-scale availability

Important:

This does not mean NoSQL is universally more scalable than SQL.

Modern relational databases can also scale extremely far.

The correct choice depends on workload and requirements.

4. SQL vs NoSQL Mental Model#

A useful simplified distinction is:

Relational model#

Start with:

Entities
Relationships
Constraints
Transactions
Queries

Then model data into tables.

NoSQL model#

Often start with:

Access patterns
Partitioning
Distribution
Latency
Availability

Then design the stored representation around those requirements.

This does not mean every NoSQL database must be designed this way, but it is an important system-design mindset.

5. The Four Major NoSQL Families#

                  NoSQL
                    |
       +------------+------------+------------+
       |            |            |            |
    Document     Key-Value   Wide-Column    Graph

Examples:

Document:
MongoDB
 
Key-Value:
Redis
Amazon DynamoDB
 
Wide-Column:
Apache Cassandra
ScyllaDB
 
Graph:
Neo4j

Some products support capabilities that overlap categories, so the classification is based on the dominant data model.

6. Document Databases#

A document database stores data as documents.

A document is often JSON-like.

Example:

{
  "id": "user_123",
  "name": "Anubhav",
  "email": "anubhav@example.com",
  "skills": [
    "JavaScript",
    "Node.js",
    "System Design"
  ],
  "address": {
    "city": "Delhi",
    "country": "India"
  }
}

The document can contain nested structures.

This can map naturally to application objects.

7. Why Documents Are Useful#

Suppose a user profile naturally looks like:

User
 |
 +-- name
 +-- email
 +-- skills[]
 +-- address
       +-- city
       +-- country

A document database can store this as one document.

Instead of:

users
addresses
user_skills

we may have:

users
  |
  +-- embedded address
  +-- embedded skills

This can simplify reads.

8. Embedding#

Embedding means storing related information inside the same document.

Example:

{
  "user_id": 123,
  "name": "Anubhav",
  "addresses": [
    {
      "type": "home",
      "city": "Delhi"
    },
    {
      "type": "work",
      "city": "Gurugram"
    }
  ]
}

Advantages:

• fewer reads
• related data retrieved together
• natural representation for bounded nested data

Potential disadvantages:

• duplicated data
• larger documents
• difficult updates if embedded data changes independently
• document size limits depending on the database

9. Referencing#

Instead of embedding:

{
  "user_id": 123,
  "address_id": 456
}

The application can store related data separately.

Conceptually:

User
 |
 +---- Address

This is useful when the related entity:

• is large
• changes independently
• is shared
• has an independent lifecycle

10. Embedding vs Referencing#

This is not an absolute rule.

The access pattern should drive the decision.

11. Document Database Example#

Suppose we have an e-commerce product:

{
  "product_id": "p100",
  "name": "Laptop",
  "price": 75000,
  "brand": "Example",
  "specifications": {
    "ram": "16GB",
    "storage": "1TB"
  }
}

Different products may have different attributes.

For example:

{
  "product_id": "p200",
  "name": "Phone",
  "price": 50000,
  "camera": {
    "rear": "50MP",
    "front": "12MP"
  }
}

A document model can represent these varying attributes naturally.

12. Flexible Schema Does Not Mean No Schema#

A common misconception:

NoSQL databases have no schema.

Incorrect.

Every production application still has a data model.

The difference is that some NoSQL systems allow more flexible or application-managed schema evolution.

For example:

Application v1
    |
    +-- name
    +-- email
 
Application v2
    |
    +-- name
    +-- email
    +-- phone

The application may need to support both document shapes during migration.

So:

Schema flexibility shifts some responsibility from the database to the application.

13. Key-Value Databases#

The simplest model is:

Key -> Value

Example:

user:123 -> {...}
session:abc -> {...}
cart:789 -> {...}

The application knows the key.

It retrieves the associated value.

14. Why Key-Value Systems Are Fast#

A common access pattern is:

GET key

or:

SET key value

This is simpler than arbitrary relational querying.

Conceptually:

Application
    |
    | key = user:123
    v
Key-Value Store
    |
    v
Value

This model is particularly useful for predictable point lookups.

15. Common Key-Value Use Cases#

Examples:

Sessions#

session:abc123
    ->
user/session data

Cache#

product:123
    ->
cached product

Rate limiting#

rate:user:123
    ->
counter

Counters#

video:123:views
    ->
1250000

Shopping carts#

cart:user:123
    ->
cart data

16. Redis#

Redis is a popular in-memory data store.

It supports more than simple strings.

Common structures include:

Strings
Hashes
Lists
Sets
Sorted Sets
Streams

Example conceptual data:

user:123
    ->
{
  name: "Anubhav",
  age: 28
}

Redis is frequently used for:

• caching
• sessions
• counters
• rate limiting
• distributed coordination
• queues in some architectures
• ephemeral state

Its exact suitability depends on the durability and consistency requirements.

17. Important Redis Mental Model#

Redis is often used as:

Application
    |
    v
Redis
    |
    +---- hit
    |
    +---- miss
           |
           v
        Database

This is why Redis is often discussed as a caching technology even though it is technically a data store with richer capabilities.

18. Wide-Column Databases#

Wide-column databases store data in a distributed structure optimized for large-scale workloads.

Examples:

Apache Cassandra
ScyllaDB

The important idea is:

Data is modeled around partition keys and query patterns.

These systems can be excellent for:

• very large datasets
• high write throughput
• distributed workloads
• predictable query patterns
• high availability

19. Cassandra Mental Model#

A simplified representation:

Partition Key
      |
      v
+-----------------------+
| Partition             |
|                       |
| clustering columns    |
| row                   |
| row                   |
| row                   |
+-----------------------+

The partition key determines where data belongs in the distributed system.

This makes partition-key design extremely important.

20. Access-Pattern-First Design#

One of the most important NoSQL concepts is:

Design the data model around the queries the application must perform.

Suppose the application needs:

Get messages for a conversation
ordered by time

Instead of first creating a generic normalized model, we ask:

What is the partition key?
What ordering is required?
What query must be fast?

Possible conceptual model:

conversation_id
        |
        +-- message 1
        +-- message 2
        +-- message 3

This is different from traditional relational modeling where normalization and relationships often come first.

21. Query-Driven Modeling#

Consider a chat application.

Required query:

Get latest 50 messages for conversation 123.

A NoSQL-oriented design might use:

Partition key:
conversation_id
 
Sort/clustering key:
message_timestamp

Then:

conversation_id = 123
timestamp DESC
LIMIT 50

can be efficient.

22. Why Generic Modeling Can Fail#

Suppose you design a NoSQL database without knowing the queries.

You may later discover:

Query A -> easy
Query B -> extremely expensive
Query C -> requires scanning
Query D -> impossible without another data model

NoSQL systems often encourage:

Start from access patterns.

23. Denormalization in NoSQL#

Denormalization is common in distributed NoSQL systems.

Suppose we need:

Get user timeline

Instead of dynamically joining:

users
posts
follows

we may maintain a precomputed timeline:

timeline:user:123
    |
    +-- post 900
    +-- post 870
    +-- post 850

This duplicates information.

But the read becomes much simpler.

24. The Trade-Off#

Denormalization can provide:

Faster reads
Simpler query path
Predictable latency

But it introduces:

More storage
More write complexity
Consistency challenges
Data duplication
Update propagation

This is one of the central NoSQL trade-offs.

25. Write Amplification#

Suppose one event must update:

User timeline
Follower timeline
Trending feed
Search index
Analytics store

One logical action may produce many physical writes.

1 logical write
       |
       +----> store A
       +----> store B
       +----> store C
       +----> store D

This is write amplification.

It can be acceptable if it produces scalable read performance.

26. Partitioning#

Partitioning means dividing data into separate partitions.

Conceptually:

All Data
   |
   +---- Partition A
   +---- Partition B
   +---- Partition C
   +---- Partition D

This allows different nodes to handle different portions of the data.

27. Sharding#

When partitions are distributed across multiple database nodes, we commonly use the term sharding.

Example:

                 Database
                    |
       +------------+------------+
       |            |            |
       v            v            v
    Shard 1      Shard 2      Shard 3

Each shard owns a subset of the data.

28. Why Sharding Helps#

Suppose one database server can process:

20,000 requests/sec

and the workload requires:

100,000 requests/sec

If the workload can be partitioned effectively:

Shard 1 -> 20K
Shard 2 -> 20K
Shard 3 -> 20K
Shard 4 -> 20K
Shard 5 -> 20K

The theoretical aggregate capacity can increase.

Real systems have coordination, network, skew, replication, and operational overhead, so scaling is not perfectly linear.

29. Partition Key#

The partition key determines where a record belongs.

Example:

user_id

might determine the partition.

Conceptually:

hash(user_id)
       |
       v
Partition

A good partition key distributes traffic and data sufficiently.

30. Good Partition Key Properties#

A good partition key often provides:

High cardinality#

Many possible values.

Even distribution#

Data is spread reasonably across partitions.

Even traffic#

Requests should not disproportionately target one partition.

Query alignment#

Common queries should be able to locate the relevant partition efficiently.

31. Bad Partition Key — Low Cardinality#

Suppose:

country

is the partition key.

If most users belong to a small number of countries:

India -> huge
USA -> huge
UK -> moderate
...

some partitions may become much larger or hotter than others.

32. Bad Partition Key — Hot Key#

Suppose:

celebrity_id = 123

receives millions of requests.

If all traffic maps to one partition:

Partition 7
    |
    +---- millions of requests

the partition becomes a bottleneck.

This is a hot partition.

33. Handling Hot Partitions#

Possible strategies include:

• choose a better partition key
• add a controlled shard suffix
• distribute popular records
• cache hot data
• replicate popular data
• redesign the access pattern

For example:

celebrity:123:0
celebrity:123:1
celebrity:123:2
...

Traffic can be spread across logical partitions.

But this makes reads more complex.

34. Hash Partitioning#

A common approach is:

partition = hash(key) % N

Example:

hash(user_id) % 4

maps users across:

0
1
2
3

This can distribute data well if the keys are suitably distributed.

35. Range Partitioning#

Another strategy is to divide data into ranges.

Example:

User IDs
 
0 - 999,999       -> Partition A
1M - 1,999,999    -> Partition B
2M - 2,999,999    -> Partition C

Range partitioning can make range queries easier.

But it can create hotspots if new writes concentrate in one range.

36. Hash vs Range Partitioning#

The correct strategy depends on workload.

37. Replication#

Replication means storing copies of data on multiple nodes.

            +--> Replica A
Primary ----+
            +--> Replica B

In some NoSQL systems, replication is built into the distributed architecture rather than being a separate read-replica pattern.

38. Why Replicate?#

Replication can improve:

• availability
• fault tolerance
• read capacity
• geographic resilience

But it also introduces:

• replication traffic
• storage cost
• consistency complexity
• failover complexity

39. Leader-Based Replication#

One model:

Leader
  |
  +----> Follower
  |
  +----> Follower

Writes go to the leader.

Followers replicate data.

Reads may go to:

Leader
or
Followers

depending on consistency requirements.

40. Leaderless Replication#

Some distributed databases use leaderless approaches.

Conceptually:

Client
  |
  +----> Node A
  +----> Node B
  +----> Node C

A write may be sent to multiple replicas.

Reads may also query multiple replicas.

This leads to quorum concepts.

41. Quorum#

Suppose:

N = 3 replicas

A system might require:

W = 2 replicas for write
R = 2 replicas for read

Since:

W + R > N

the read and write sets overlap.

Conceptually:

3 replicas
A B C
 
Write -> A B
 
Read  -> B C
 
Overlap -> B

This can help a read observe a recent write under appropriate system assumptions.

But:

Quorum mathematics alone does not fully describe consistency.

Real systems have additional details around failures, conflict resolution, repair, timestamps, and read/write semantics.

42. Eventual Consistency#

Eventual consistency means that replicas may temporarily disagree, but if updates stop and the system remains healthy, replicas are expected to converge.

Example:

Write:
User name = Anubhav
 
Replica A -> Anubhav
Replica B -> Anubhav
Replica C -> old value

For a short period, different reads may return different values.

Later:

A -> Anubhav
B -> Anubhav
C -> Anubhav

This is eventual convergence.

43. Stronger vs Weaker Consistency#

Think of a spectrum:

Stronger consistency
       |
       v
More coordination
More latency in some designs
Potentially less availability during some failures
       |
       v
Weaker consistency
       |
       v
More asynchronous behavior
Potentially lower latency
Potentially stale reads

The correct point depends on business requirements.

44. Where Eventual Consistency Can Work#

Examples:

Social media likes
View counts
Recommendations
Search indexes
Activity feeds
Analytics

A small delay may be acceptable.

45. Where Stronger Guarantees May Matter#

Examples:

Financial balances
Payment state
Inventory constraints
Security permissions
Certain order states

The exact requirements must be analyzed carefully.

Not every financial system needs the same consistency mechanism for every component.

46. CAP Theorem Preview#

We will study CAP deeply later.

For now, understand the basic idea:

In a distributed system subject to a network partition, you cannot simultaneously guarantee both:

Strong consistency
and
Availability

in the simplistic sense captured by CAP.

CAP is about:

Consistency
Availability
Partition tolerance

The crucial point:

Network partitions are possible in distributed systems, so system design must define what happens when communication fails.

We will dedicate a later chapter to this.

47. NoSQL Transactions#

A common misconception:

NoSQL databases do not support transactions.

Incorrect.

Many modern NoSQL systems support transactions, although capabilities vary considerably.

Examples may include:

• single-document atomicity
• conditional writes
• multi-item transactions
• compare-and-set operations

The important question is:

What transaction scope and guarantees does this particular database provide?

48. Single-Document Atomicity#

Document databases often make operations on one document atomic.

Example:

{
  "balance": 1000,
  "status": "active"
}

An update can modify the document atomically according to the database's semantics.

This is one reason document modeling often encourages embedding data that must change together.

49. Conditional Writes#

A distributed database may support operations like:

Update only if version = 10

Conceptually:

Current version = 10
       |
       v
Update succeeds
       |
       v
Version = 11

If another writer changed the version first:

Current version = 11
 
Expected = 10
 
Update fails

This is useful for optimistic concurrency control.

50. Optimistic Concurrency#

Suppose:

Product stock = 5
Version = 10

Two requests read:

stock = 5
version = 10

Both attempt to update.

Request A:

version 10 -> 11

succeeds.

Request B:

expected version = 10

fails because the version is now 11.

This prevents blind overwrites.

51. Secondary Indexes#

NoSQL databases may support indexes beyond the primary key.

But secondary indexes can have different:

• scalability characteristics
• consistency behavior
• query limitations
• write costs

Always understand the database-specific implementation.

For distributed systems, a secondary index can itself become a distributed system component.

52. TTL#

TTL means:

Time To Live.

A record can automatically expire after a configured duration.

Example:

session:abc
TTL = 30 minutes

After expiration, the data can be removed according to the database's TTL mechanism.

Common uses:

• sessions
• temporary tokens
• caches
• ephemeral events
• temporary locks
• short-lived data

53. NoSQL and Caching#

Some NoSQL systems are themselves used as caching layers.

Example:

Application
    |
    v
Redis
    |
    +---- hot data

But not all NoSQL databases are caches.

For example:

Cassandra
MongoDB
DynamoDB

can be durable databases for primary application data depending on architecture.

Always distinguish:

Database
vs
Cache

based on durability and source-of-truth requirements.

54. NoSQL and Durability#

NoSQL does not automatically mean:

in-memory

Some NoSQL systems are durable disk-backed databases.

Others may be primarily memory-oriented.

The correct question is:

What durability guarantees does the specific system provide?

55. Polyglot Persistence#

Large systems may use multiple database technologies.

Example:

                    Application
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
       SQL DB          Redis        Document DB
      payments         cache          profiles

Another example:

Transactions -> PostgreSQL
Cache        -> Redis
Events       -> Cassandra
Search       -> Search engine
Analytics    -> Data warehouse

This is called polyglot persistence.

56. Why Use Multiple Databases?#

Because different workloads have different requirements.

For example:

Payments
  -> strong transactional guarantees
 
Sessions
  -> fast key lookup
 
Product catalog
  -> document-like structure
 
Search
  -> inverted indexes
 
Analytics
  -> large scans/aggregations

One database may not be ideal for every workload.

57. Polyglot Persistence Trade-Offs#

Benefits:

Best-fit technology
Workload specialization
Potential scalability

Costs:

Operational complexity
Multiple backup systems
Multiple monitoring systems
Data synchronization
More developer knowledge
More failure modes

Therefore:

Do not introduce multiple databases without a strong reason.

58. SQL vs Document Example#

Suppose we have:

User profile

If the profile is mostly retrieved as one complete object:

user
  |
  +-- profile
  +-- preferences
  +-- addresses

a document model may be convenient.

If the system needs complex relationships:

users
orders
payments
products
subscriptions

with multi-entity transactions and queries, a relational model may be a natural fit.

59. SQL vs Wide-Column Example#

Suppose an application stores:

billions of events

and primarily queries:

events for user X ordered by timestamp

A distributed wide-column system may be attractive if its operational characteristics fit the workload.

But if the application requires:

arbitrary joins
complex transactions
ad-hoc relational queries

a relational database may be more appropriate.

60. SQL vs Key-Value Example#

Suppose the workload is:

session_id -> session

The application knows the key.

A key-value database can be a natural fit.

But if the requirement becomes:

Find all users
whose subscription expires
within 7 days
and whose last purchase
exceeded ₹10,000

a relational or analytical system may be more suitable.

61. Database Selection Framework#

Ask these questions:

1. What is the data model?#

Relational?
Document?
Key-value?
Wide-column?
Graph?

2. What are the access patterns?#

Point lookup?
Range query?
Aggregation?
Relationship traversal?

3. What scale is required?#

Data size
Reads/sec
Writes/sec
Traffic growth

4. What consistency is required?#

Strong?
Eventual?
Application-specific?

5. What transaction scope is needed?#

Single record?
Multiple records?
Multiple services?

6. What availability is required?#

Single zone?
Multi-zone?
Multi-region?

7. What latency is required?#

Sub-millisecond?
Milliseconds?
Seconds?
Batch?

8. What operational complexity can the team handle?#

This last question is often overlooked.

62. Real-World Example — Social Media Feed#

Suppose:

100M users
High read traffic
Users follow many accounts
Posts are frequent
Feed reads must be fast

One possible architecture:

Post creation
     |
     v
Event / Queue
     |
     v
Fan-out workers
     |
     v
Timeline store
     |
     v
User timeline

The timeline may be stored in a distributed key-value or wide-column system.

Why?

Because the critical access pattern is:

Get recent posts for user X

The data model can be optimized around this query.

63. Real-World Example — Chat System#

Requirement:

Get recent messages for conversation X.

A suitable distributed model might be:

partition key = conversation_id
sort key      = message timestamp

Conceptually:

Conversation 123
 |
 +-- 10:01 message
 +-- 10:02 message
 +-- 10:03 message
 +-- 10:04 message

This makes:

latest 50 messages

a natural access pattern.

64. Real-World Example — Session Store#

Requirement:

Get session by session ID

A key-value model:

session:abc123
   ->
session data

is simple.

Potential architecture:

Application
    |
    v
Session Store
    |
    v
Session

If sessions are ephemeral, TTL can automatically remove expired data.

65. Real-World Example — Product Catalog#

Suppose product attributes vary significantly.

Phone:
camera
battery
screen
 
Laptop:
processor
ram
storage
 
Shoes:
size
material
color

A document database can naturally represent variable product attributes.

But search requirements may justify a separate search engine.

This is another example of polyglot persistence.

66. NoSQL Failure Modes#

Distributed NoSQL systems can fail in many ways:

Node failure
Network partition
Hot partition
Replication lag
Write conflicts
Unavailable quorum
Clock issues
Storage failure
Uneven data distribution

A system-design interview should not stop at:

It scales horizontally.

You should ask:

How does it behave when a node or network link fails?

67. Hot Partition Example#

Suppose:

1 billion users

but traffic is highly concentrated on:

user_id = 123

If:

hash(user_id)

maps all requests for user 123 to one partition, that partition can become a bottleneck.

Adding more partitions does not automatically solve the hot key.

This is a major distributed database design lesson.

68. Data Distribution vs Traffic Distribution#

A partition can be balanced by data size but still be unbalanced by traffic.

Example:

Partition A -> 100 GB -> 1,000 req/sec
Partition B -> 100 GB -> 100,000 req/sec

Data is balanced.

Traffic is not.

Therefore:

Partition-key design must consider both data distribution and access distribution.

69. Consistency vs Latency#

Suppose replicas are geographically distributed:

India
Europe
US

A write may need confirmation from multiple regions for stronger guarantees.

This can increase latency.

Alternatively, the system may acknowledge locally and replicate asynchronously.

That may reduce write latency but increase the window for stale reads or conflict handling.

This is a classic distributed-system trade-off.

70. NoSQL and Global Systems#

A globally distributed application might look like:

             Global Traffic
                   |
          +--------+--------+
          |        |        |
          v        v        v
       Region A Region B Region C
          |        |        |
          +--------+--------+
                   |
             Replicated Data

Design questions include:

• Where should writes go?
• Where should reads go?
• What happens during a region outage?
• How stale can data be?
• How are conflicts resolved?
• What is the recovery process?

These questions become central in later chapters.

71. Common NoSQL Mistakes#

Mistake 1: "NoSQL means no schema."#

Wrong.

NoSQL often means more flexible schema enforcement, not absence of data modeling.

Mistake 2: "NoSQL is always faster."#

Wrong.

Performance depends on workload and access patterns.

Mistake 3: "NoSQL means eventual consistency."#

Not universally.

Different systems provide different consistency options.

Mistake 4: "NoSQL cannot do transactions."#

Wrong.

Many systems support some form of transactional or atomic operations.

Mistake 5: "Sharding automatically solves scale."#

Not necessarily.

Bad partition keys can create:

hot partitions

and uneven load.

Mistake 6: "More partitions always improve performance."#

More partitions can increase:

• routing complexity
• metadata
• coordination
• operational overhead

The system must be designed appropriately.

Mistake 7: "Denormalization is free."#

No.

You trade:

read efficiency

for:

write complexity
consistency management
storage

Mistake 8: "Use one database for everything."#

Sometimes a single database is exactly the right choice.

But different workloads may justify specialized systems.

72. Interview Questions#

Beginner#

Q1. What is NoSQL?#

A family of non-relational database systems with different data models and operational characteristics.

Q2. What are the major NoSQL categories?#

Document
Key-value
Wide-column
Graph

Q3. What is a document database?#

A database that stores records as document-like structures, commonly JSON-like.

Q4. What is a key-value database?#

A system based primarily on:

key -> value

lookups.

Q5. What is a graph database?#

A database optimized around nodes, edges, and relationships.

73. Intermediate Interview Questions#

Q6. Why is NoSQL often modeled around access patterns?#

Because many distributed NoSQL systems optimize predictable queries and partition-based access rather than arbitrary joins.

Q7. What is a partition key?#

A value used to determine where data is distributed.

Q8. What is a hot partition?#

A partition receiving disproportionately high traffic or data.

Q9. What is eventual consistency?#

Replicas may temporarily differ but can converge after updates propagate.

Q10. What is denormalization?#

Duplicating data to make important access patterns faster or simpler.

74. Advanced Interview Questions#

Q11. How would you choose a partition key?#

Consider:

Cardinality
Distribution
Traffic distribution
Query patterns
Data size
Growth
Hot-key risk

Q12. How do you handle a hot key?#

Potential approaches:

Caching
Key spreading
Sharded key
Replication
Request coalescing
Access-pattern redesign

The correct choice depends on workload.

Q13. SQL vs NoSQL — which would you choose?#

Do not answer:

SQL is better.

or:

NoSQL is better.

Instead explain:

Data model
Queries
Transactions
Consistency
Scale
Availability
Latency
Operational requirements

Then select a technology that fits those requirements.

Q14. Why does denormalization help NoSQL systems?#

Because it can eliminate expensive joins and make common queries direct partition lookups.

Q15. What is polyglot persistence?#

Using multiple storage technologies in one system, each selected for a specific workload.

75. Practical Exercise#

Design storage for a social media application.

Requirements:

Users can follow users.
 
Users create posts.
 
Users view their timeline.
 
Users like posts.
 
Users comment on posts.

Define:

Query 1#

Get a user's recent timeline.

Query 2#

Get recent posts by a user.

Query 3#

Get comments for a post.

Query 4#

Check whether a user liked a post.

Query 5#

Get followers of a user.

For each query, determine:

Key
Partition key
Sort key
Potential database model
Potential index
Potential caching strategy

76. Mini Project — Distributed Chat Store#

Design a NoSQL data model for:

Chat application

Requirements:

Users can create conversations.
 
A conversation contains messages.
 
Users can send messages.
 
Users can retrieve recent messages.
 
Messages have timestamps.
 
Users may belong to many conversations.

Design the data model around these access patterns:

Get conversation
Get latest 50 messages
Get messages after timestamp X
Get conversations for user
Check membership

For each query identify:

Partition key
Sort key
Expected result size
Hot-key risk
Consistency requirement

77. Design Exercise — Global Session Store#

Suppose:

10 million active sessions
500,000 requests/sec
Users distributed globally
Sessions expire after 30 minutes

Design:

Key format
Value format
TTL
Partition strategy
Replication
Read strategy
Failure handling

Think about:

session:user:123

versus:

session:<random-id>

Which key better distributes traffic?

The answer depends on the actual access pattern and distribution.

78. NoSQL Production Checklist#

Before deploying a NoSQL database, ask:

Data model#

• What is the entity?
• What are the access patterns?
• What data should be embedded?
• What should be referenced?

Partitioning#

• What is the partition key?
• Is it high-cardinality?
• Is data evenly distributed?
• Is traffic evenly distributed?
• Can hot keys appear?

Consistency#

• What consistency is required?
• Can stale data be tolerated?
• What happens during replication lag?

Availability#

• How many replicas?
• What happens when a node fails?
• What happens during a network partition?

Performance#

• What is the expected read/write rate?
• What is the expected latency?
• Are queries partition-local?

Operations#

• Backups
• Monitoring
• Capacity planning
• Repair/recovery
• Schema/data migrations

79. Master Mental Model#

Think of NoSQL architecture like this:

                    Application
                         |
                         v
                   Access Patterns
                         |
                         v
                    Data Model
                         |
                         v
                  Partition Key
                         |
                         v
                    Partition
                         |
             +-----------+-----------+
             |           |           |
             v           v           v
          Replica      Replica     Replica
             |           |           |
             +-----------+-----------+
                         |
                    Consistency
                         |
                         v
                   Failure Model

This is the key mindset for distributed database design.

80. SQL vs NoSQL Decision Table#

These are starting points, not universal rules.

81. Chapter Summary#

The biggest lesson from this chapter is:

NoSQL is a collection of different database approaches, not a single technology.

The major families are:

Document
Key-Value
Wide-Column
Graph

And the core distributed concepts are:

Access patterns
       ↓
Data modeling
       ↓
Partitioning
       ↓
Replication
       ↓
Consistency
       ↓
Failure handling

At scale:

Data
 |
 +-- partition
 |
 +-- replicate
 |
 +-- distribute
 |
 +-- optimize access
 |
 +-- handle failures

The most important system-design rule is:

Design the database around the workload, access patterns, consistency requirements, scale, and failure model—not around the popularity of a database technology.

82. Master Checklist#

You should now be able to explain:

• What NoSQL means
• Why NoSQL systems exist
• Document databases
• Key-value databases
• Wide-column databases
• Graph databases
• Flexible schemas
• Embedding
• Referencing
• Access-pattern-first design
• Denormalization
• Write amplification
• Partitioning
• Sharding
• Partition keys
• Hash partitioning
• Range partitioning
• Hot partitions
• Hot keys
• Replication
• Leader-based replication
• Leaderless replication
• Quorum concepts
• Eventual consistency
• Stronger consistency
• CAP theorem basics
• NoSQL transactions
• Conditional writes
• Optimistic concurrency
• Secondary indexes
• TTL
• Polyglot persistence
• SQL vs NoSQL
• Database selection
• NoSQL failure modes
• Distributed database trade-offs

83. What Comes Next?#

Chapter 12 — Database Indexing#

Next we will go deep into database indexing.

We will learn:

Why indexes exist
        ↓
How indexes work internally
        ↓
B-Tree indexes
        ↓
Hash indexes
        ↓
Composite indexes
        ↓
Covering indexes
        ↓
Clustered vs non-clustered indexes
        ↓
Cardinality and selectivity
        ↓
Index scan vs sequential scan
        ↓
Query planner
        ↓
EXPLAIN
        ↓
Index design
        ↓
Index anti-patterns
        ↓
Write amplification
        ↓
Large-table indexing
        ↓
Production indexing strategies

This chapter will go much deeper into how indexes actually make database queries fast—and when an index can make a system slower instead.