Data Layer
Scaling with
NoSQL Group-02
name Id
Adnan uddin 22701011
Kamrul Arafin 22701016
Meheer Ali Khan 22701034
Table of Contents
Scaling with NoSQL
The Rise of Eventual Consistency
Faster Recovery to Increase Availability
Cassandra Topology
summary
Table of Contents
Scaling with NoSQL
The Rise of Eventual Consistency
Faster Recovery to Increase Availability
Cassandra Topology
summary
Table of Contents
Scaling with NoSQL
The Rise of Eventual Consistency
Faster Recovery to Increase Availability
Cassandra Topology
summary
Table of Contents
Scaling with NoSQL
The Rise of Eventual Consistency
Faster Recovery to Increase Availability
Cassandra Topology
summary
Table of Contents
Scaling with NoSQL
The Rise of Eventual Consistency
Faster Recovery to Increase Availability
Cassandra Topology
summary
Table of Contents
Scaling with NoSQL
The Rise of Eventual Consistency
Faster Recovery to Increase Availability
Cassandra Topology
summary
Why NoSQL Emerged
Traditional relational databases became the biggest bottleneck in
scaling web applications.
RDBMS relied heavily on normalization, strict ACID transactions, stored
procedures, and centralized logic — great for consistency, but poor for
large distributed workloads.
Scaling required vertical growth: bigger servers, expensive licenses, and
rigid architectures.
With the rise of massive online platforms, this model became
unsustainable, triggering the search for new, more scalable data
systems.
Normalization – The Classical Data Model
Data is structured into multiple related tables to reduce redundancy and
storage cost.
Each row is uniquely identified with a primary key; relationships are
maintained through foreign keys.
Benefits include: smaller data footprint, efficient indexing, cleaner
queries, and strong data integrity.
However, heavy normalization increases join complexity and makes
horizontal distribution difficult, limiting scalability.
Rise of NoSQL Systems
In the 2000s, companies like Amazon, Google, and Facebook pushed
scalability boundaries.
They built custom distributed data stores that removed SQL, removed
triggers, and simplified the data model to prioritize large-scale
performance.
These systems delivered true horizontal scalability, high availability, and
fault tolerance, far beyond traditional databases.
Foundational papers (Google File System, MapReduce, BigTable, Amazon
Dynamo) inspired open-source systems such as Cassandra, Redis,
MongoDB, Riak, and CouchDB — launching the NoSQL era.
What NoSQL Really Means
NoSQL refers to a broad family of non-relational, distributed data stores
optimized for scaling across many servers.
Most NoSQL systems don’t use SQL and instead focus on simple data
models: key-value, document, column-family, and graph.
Designed to support massive data volume, low latency, and high
availability across distributed environments.
They intentionally make tradeoffs, prioritizing scalability and
performance over strict relational guarantees.
The NoSQL Mindset – Designing with Tradeoffs
Before choosing a NoSQL database, you must define which features
matter most: availability, latency, consistency, ease of development, or
transaction guarantees.
No single system can excel at all dimensions — each NoSQL technology
sacrifices something to optimize its priorities.
The goal is not to find a “better SQL,” but to choose the right tool that
aligns with your specific scalability needs.
Successful architectures embrace these tradeoffs rather than trying to
force every use case into one database model.
CAP Theorem – The Foundation of NoSQL Tradeoffs
CAP states you cannot achieve Consistency, Availability, and Partition
Tolerance simultaneously in a distributed system.
Consistency: every node sees the same data at the same time.
Availability: every request receives a response, even during failures.
Partition Tolerance: the system must continue working despite network
partitions.
The famous (but simplified) phrase “pick two” highlights that scalable
systems require prioritization.
CAP helped explain why NoSQL systems make intentional sacrifices and
why relational-style guarantees can’t magically scale across distributed
nodes.
Why Eventual Consistency?
Distributed systems must trade off Consistency, Availability, Partition
Tolerance (CAP).
Amazon’s Dynamo prioritized high availability over strict consistency.
Goal: never show blank pages or lose shopping cart data.
Result: eventual consistency becomes a practical solution for massive-
scale systems.
Understanding Eventual Consistency
Nodes may temporarily have different versions of data.
Updates propagate asynchronously; all nodes converge eventually.
Reads can return stale data, but the system ensures eventual
convergence.
Enables high availability, allowing reads and writes without waiting for
full synchronization.
Handling Conflicts
Conflicts arise when multiple clients update the same data concurrently.
Resolution strategies:
Last Write Wins (LWW): newest update overwrites older versions.
Client-Side Resolution: system returns all conflicting versions; client
merges them.
Example: Amazon shopping cart merges items to prevent data loss.
Systems like Cassandra use read repair and self-healing to synchronize
replicas automatically.
Tunable & Quorum Consistency
Some NoSQL systems allow query-level consistency tuning.
Tradeoffs:
Higher consistency → higher latency
Higher availability → possible stale reads
Quorum consistency: majority of replicas confirm writes/reads →
ensures freshest data and read-after-write guarantees.
Combines flexibility, scalability, and resilience.
Availability vs Consistency in NoSQL
Some NoSQL systems trade high availability for strong consistency and
fast recovery.
MongoDB shards data across servers; each piece belongs to a single
server.
If a server fails, writes to that data are rejected until recovery, preserving
global consistency.
Replica Sets and Failover
MongoDB uses replica sets: multiple nodes share the same data; one
node acts as primary.
On primary failure:
New primary is elected automatically.
Replication resumes to remaining nodes, minimizing downtime.
Replica sets reduce unavailability while maintaining consistency.
Replication & Consistency Nuances
Replica sets replicate asynchronously: primary writes first, then
propagate to secondaries.
If primary fails before replication, some writes may be lost.
Secondary node consistency can be enforced per write, but it’s
resource-intensive.
NoSQL systems often behave subtly different than documentation;
assumptions can be risky.
Cassandra Overview & Data Model
Originally built at Facebook, inspired by BigTable and Dynamo.
All nodes are functionally equal; no single point of failure.
Clients connect to any node (session coordinator) — coordinator
handles replication, partitioning, and query delegation.
Automatic data partitioning: each node stores a subset of data.
Wide-column model: tables independent, rows may have different
columns, dynamic schema allows rapid changes.
Row key-based partitioning: coordinator hashes row key to locate
responsible node.
Replication, Consistency & Failover
Supports replication: multiple copies across cluster, no master-slave.
Quorum writes: coordinator waits for majority acknowledgment to
ensure consistency.
Hinted handoff: writes buffered and replayed when failed nodes
recover.
Cluster remains operational during node failures or replacements.
Scalability, Tradeoffs & Caveats
Horizontal scalability: adding nodes increases read/write capacity;
cluster rebalances automatically.
Minimal administration; self-healing and automated node replacement.
Eventual consistency: quorum reads/writes required for strict
consistency.
Deletes are expensive due to append-only design; high delete/update
workloads can degrade performance.
Cassandra offers great performance and scalability but requires deep
understanding of its tradeoffs and internal behavior.
Summary and Key Takeways
Data layer is the hardest part to scale.
Use functional partitioning, replication, and sharding for
horizontal scaling.
Every database has tradeoffs — no one-size-fits-all.
Polyglot persistence: mix different data stores based on use case.
Research pitfalls before choosing NoSQL technologies.
I/O bottlenecks remain — caching is a key strategy to reduce load.
THANK YOU