Week 10 — DBMS NoSQL, Redis & Scaling

intermediate dbms dsa

Goal: “Not everything is a nail, so not everything needs a SQL hammer.” — This week we explore the other side of the database world — NoSQL, Redis, and scaling patterns. By Friday, we’ll have completed the entire DBMS track. That’s a massive milestone.

Topics

DayTrackFocusTopics
MonA — DSA PracticeTree Problems (BST, Traversals)Solve 2-3 problems. Focus on BST validation, lowest common ancestor, and level-order traversal.
TueB — DBMSNoSQL DatabasesDocument Stores · Key-Value Stores · Wide-Column Stores · Graph Databases · NoSQL Data Modeling
WedA — DSA PracticeTrie ProblemsSolve 2-3 problems. Implement a trie from scratch, then try word search and auto-complete variants.
ThuB — DBMSRedis Deep DiveChoosing the Right Database · Redis Data Types and Commands · Redis Persistence · Caching Patterns · Redis Eviction and Expiry · Redis Pub/Sub and Distributed Locks
FriB — DBMSScaling & PatternsReplication · Sharding · Connection Pooling · CQRS and Event Sourcing · Database per Service and CDC

Note: This week completes the entire DBMS collection! We’ve gone from “what is a database” all the way to sharding, CQRS, and change data capture. Starting next week, we enter system design territory. Everything we’ve learned about databases becomes the foundation for designing scalable systems.

Key Concepts

  • Document stores (MongoDB) are great for flexible, evolving schemas — think user profiles, product catalogs. Key-value stores (Redis) are the fastest option when we just need to look things up by a key.
  • Redis is both a cache AND a data structure server. It supports strings, lists, sets, sorted sets, hashes, streams, and more. Don’t think of it as “just a cache.”
  • Caching patterns matter: cache-aside (lazy loading) is the most common, write-through ensures cache consistency but adds latency, write-behind batches writes for performance but risks data loss.
  • Replication = copies for reads (scale horizontally for read-heavy workloads). Sharding = splitting data across nodes for writes (scale horizontally for write-heavy workloads). Most production systems use both.
  • CDC (Change Data Capture) captures database changes as a stream of events. It’s how we keep multiple services in sync without tight coupling — essential for microservices architectures.

Practice

  • DSA: Solve 5-6 tree and trie problems this week — include at least one BST problem and one trie implementation
  • DBMS: Design a caching strategy for a read-heavy social media feed — which pattern would we use and why?
  • DBMS: Given a scenario (e-commerce, real-time chat, social graph), explain when we’d pick MongoDB over PostgreSQL and vice versa
  • DBMS: Sketch out how we’d shard a users table — what would be our shard key and why?

~16 topics + DSA practice · ~2 hrs/day · DBMS complete! System design starts next week