📚 Comprehensive

🎨 Highly Visual

💡 Practical Examples

⚙️ Deep Technical

📘

⚙️

🗂️

🕸️

ACID Transactions

Guaranteed consistency, perfect for banking and accounting

Complex Queries

SQL's power for multi-table analysis and reporting

Structured Data

Fixed schema ensures data consistency and integrity

Enterprise Grade

Mature tools, wide adoption, standardized

The Numbers Grew

• 2000: Google processes billions of pages
• 2006: Facebook hits 100M users
• 2010: Twitter handles millions of tweets/day
• 2020: Billions of users globally

💥 SQL's Response: "Buy bigger servers" → Vertical scaling only → Exponential costs

Example: A large SQL database might cost $50K for a server. Double the data? Now you need a $100K+ server. Processing hits limits of single machine.

Requirements Changed Fast

• Need to add new fields? ALTER TABLE locks the DB
• Schema changes = downtime = lost revenue
• Different users need different fields
• Startup agility killed by rigid schemas

💥 SQL's Response: "Plan better" → Slow to change → Can't innovate

Example: Twitter wants to add emoji support. Add new column? 3-hour downtime. Millions of users can't tweet. Stock price drops.

Storage Explosion

Terabytes impossible on single server. Need distributed storage across many machines.

Performance Degradation

Complex JOINs on massive tables = queries taking minutes. Users leave.

Schema Rigidity

Startups can't pivot. Every change = database migration = expensive, time-consuming.

Cost Explosion

Vertical scaling becomes prohibitively expensive. $100K+ per year for database servers.

🏠 Google BigTable (2006)

Google publishes paper on their distributed database handling petabytes of data. Revolutionizes thinking about databases at scale.

🛍️ Amazon DynamoDB (2007)

Amazon releases paper on "Dynamo" - a highly available, scalable distributed datastore. Inspired by BigTable and Memcached concepts.

🍃 MongoDB Launched (2009)

First popular document-oriented database. JSON-like documents attract developers coming from dynamic languages. Easy to learn.

🔗 Apache Cassandra / HBase (2008-2009)

Open-source implementations of distributed databases. Cassandra from Facebook, HBase inspired by BigTable. Democratize scale technology.

Extreme Performance

Optimized for specific access patterns. Sacrifice generality for blazing speed on common operations.

Horizontal Scalability

Add more cheap servers. Distribute data across cluster. Linear cost scaling instead of exponential.

Flexible Schema

No schema enforcement. Applications define structure dynamically. Perfect for agile development.

Cost Effective

Run on cheap commodity hardware. Open source options free. No licensing fees to pay.

C Consistency

• Every read returns latest write
• ACID database like PostgreSQL
• Strict synchronization
• Can be slow when replicas far apart

A Availability

• 99.99% uptime guarantee
• Always returns data (even if stale)
• No timeouts or errors
• Prioritizes responsiveness

P Partition Tolerance

• Survives network splits
• Distributed across regions
• No single point of failure
• Modern internet requires this

Examples

• 🔷 PostgreSQL + Replication
• 🔷 MongoDB with strong consistency
• 🔷 Traditional SQL databases
• 🔷 HBase (configured for consistency)

Use When:

✅ Data accuracy is critical (banking, inventory)
✅ Network is reliable (single datacenter)
✅ Down time acceptable during partition

Examples

• 🔶 Cassandra
• 🔶 DynamoDB
• 🔶 Redis (eventually consistent)
• 🔶 Riak, Memcached

Use When:

✅ Uptime is critical (social media)
✅ Can tolerate stale data temporarily
✅ Global distribution required
✅ Downtime = lost revenue

🔒 Strong Consistency

Every read returns most recent write.

• Used: PostgreSQL, MySQL
• Cost: Slower writes
• Best for: Banking, financial data

🧬 Causal Consistency

Causally related events seen in order.

• Used: Some NoSQL systems
• Cost: More coordination overhead
• Best for: Social media posts & comments

👤 Session Consistency

User's own writes always visible within their session.

• Used: DynamoDB, Cassandra configured
• Cost: Session tracking
• Best for: Web applications

📉 Weak Consistency

No immediate consistency guarantees.

• Used: Cache systems, memcached
• Cost: Application must handle
• Best for: Caching, performance

🌊 Eventual Consistency

Eventually converges, timeline unclear.

• Used: Cassandra, Riak, DNS
• Cost: Acceptable delay
• Best for: Distributed systems, global scale

🔑

📄

📊

🕸️

Data Model Visualization

// STRING operations
SET mykey "Hello"        → Store string
GET mykey                → "Hello"
APPEND mykey " World"   → "Hello World"
STRLEN mykey             → 11

// COUNTER (atomic increment)
INCR page:views          → 1
INCR page:views          → 2
INCRBY page:views 10    → 12

// LIST operations (queue/stack)
LPUSH queue task1        → Add to left
RPUSH queue task2        → Add to right
LRANGE queue 0 -1     → [task1, task2]
LPOP queue               → task1 (remove & return)

// SET operations (unique values)
SADD users:online amine   → Add member
SADD users:online ahmed     → Add member
SMEMBERS users:online    → {amine, ahmed}
SISMEMBER users:online amine → true

// SORTED SET (leaderboard)
ZADD leaderboard 100 amine  → alice: 100 points
ZADD leaderboard 200 ahmed    → bob: 200 points
ZREVRANGE leaderboard 0 1 WITHSCORES
→ ahmed (200), amine (100)

// HASH operations (objects)
HSET user:1001 name amine   → Set field
HSET user:1001 age 28     → Set field
HGETALL user:1001         → {name: amine, age: 28}

// EXPIRATION (key disappears after timeout)
SETEX temp_data 3600 "value"  → Expires in 1 hour
TTL temp_data            → 3599 (seconds remaining)
        

⚡ Performance Characteristics

Memcached

• Pure caching: No persistence
• Simple: Get/set/delete only
• Distributed: Consistent hashing
• Use: Database query cache
• TTL: Auto-expire old items

AWS DynamoDB

• Serverless: Fully managed by AWS
• Scalable: Unlimited capacity
• Global: Multi-region replication
• Features: Indexes, streams
• Cost: Pay-per-request or provisioned

Document Structure Example

// CREATE (Insert)
db.users.insertOne({
  name: "Amine",
  email: "amine@example.com",
  age: 28
})

// READ (Query)
db.users.findOne({ name: "Amine" })
db.users.find({ age: { $gte: 25 } }) // age >= 25
db.users.find({ hobbies: "coding" })  // contains value

// UPDATE
db.users.updateOne(
  { name: "Amine" },
  { $set: { age: 29 } }
)

// DELETE
db.users.deleteOne({ name: "Amine" })

// AGGREGATION (complex queries)
db.users.aggregate([
  { $match: { age: { $gte: 25 } } },
  { $group: { _id: null, avgAge: { $avg: "$age" } } },
  { $sort: { avgAge: -1 } }
])

// CREATE INDEX for fast queries
db.users.createIndex({ email: 1 })
db.users.createIndex({ age: 1, city: 1 })  // compound
        

Key Characteristics

• Distributed: Data spread across many servers
• Highly Available: No single point of failure
• Fault-tolerant: Survives node failures
• Scalable: Linear scaling with nodes
• Fast writes: Optimized for write-heavy
• Eventual consistency: BASE model

Architecture Visualization

Social Network Graph Example

Nodes: Amine, Ahmed, Moh (people)
Relationships: FRIENDS, KNOWS, WORKS_WITH (connections with properties)

// CREATE nodes
CREATE (amine:Person { name: 'Amine', age: 28 })
CREATE (ahmed:Person { name: 'Ahmed', age: 32 })

// CREATE relationships
MATCH (amine:Person {name: 'Amine'}), (ahmed:Person {name: 'Ahmed'})
CREATE (amine)-[:FRIENDS_WITH {since: 2020}]->(ahmed)

// QUERY: Find all friends of Amine
MATCH (amine:Person {name: 'Amine'})-[:FRIENDS_WITH]->(friend)
RETURN friend.name

// QUERY: Find friends of friends (2 hops)
MATCH (amine:Person {name: 'Amine'})-[:FRIENDS_WITH*2]->(friendOfFriend)
RETURN friendOfFriend.name

// QUERY: Find shortest path between two people
MATCH path=shortestPath(
  (amine:Person {name: 'Alice'})-[*]->(moh:Person {name: 'Moh'})
)
RETURN path

// QUERY: Recommendation engine - People who like what Alice likes
MATCH (amine:Person {name: 'Amine'})-[:LIKES]->(movie)←[:LIKES](person)
WHERE person.name <> 'Amine'
RETURN person.name, count(*) as common_likes
ORDER BY common_likes DESC

// UPDATE relationship
MATCH (amine)-[r:FRIENDS_WITH]-(ahmed)
SET r.strength = 9

// DELETE
MATCH (amine)-[r:FRIENDS_WITH]-(ahmed)
DELETE r
      

Lab 1: Build a Caching Layer

Objective: Implement Redis caching for a blog API to reduce database hits by 90%

• Create API endpoint that fetches blog posts
• Check Redis cache first
• If miss, query database and cache result (5 min TTL)
• Measure improvement in response time
• Implement cache invalidation on post update

Lab 2: Design MongoDB Schema

Objective: Model an e-commerce application with flexible product data

• Design collections for Products, Orders, Users
• Handle varying product attributes (book ≠ laptop)
• Create indexes for common queries
• Write aggregation pipeline for bestsellers
• Load 1M+ products and measure performance

Lab 3: Build a Social Graph

Objective: Create Neo4j social network with recommendations

• Create Person nodes with profiles
• Create FRIENDS relationships
• Find shortest path between users
• Implement "friends of friends" feature
• Write recommendation query for new connections