← Back to Topics

Topic 3: NoSQL – Key-Value Stores Beyond Caching

Redis, DynamoDB, and Scalable Key-Value Design Patterns

Topic Overview

Key-value stores implement a minimal data model where each key maps to a single value, enabling O(1) lookup operations and high write throughput. While historically used for caching, systems like Redis and DynamoDB function as primary databases for applications requiring low-latency access patterns, horizontal scalability, and schema flexibility. The key-value model trades query expressiveness for performance: complex queries requiring joins or aggregations are not supported, but simple lookups and updates achieve sub-millisecond latency. Redis provides in-memory storage with optional persistence, while DynamoDB offers distributed, managed storage with configurable consistency guarantees. This topic examines when key-value stores replace relational databases, how to model data within key-value constraints, and common scaling challenges. Students must evaluate when key-value stores provide sufficient functionality versus when relational or document databases are necessary.

Student Presentation Assignments

Student 1:Key-Value Store Fundamentals

Required Coverage:

  • Must formally define the key-value data model, specifying supported operations and how they differ from relational operations
  • Must compare strong vs eventual consistency, analyzing trade-offs and identifying use cases where each is appropriate
  • Must justify key-value store selection for at least two use cases beyond caching (e.g., session storage, leaderboards), explaining why relational databases are unsuitable
  • Must compare Redis vs DynamoDB across architecture, consistency models, and deployment models, analyzing when each is preferable
  • Must identify scenarios where key-value stores can replace relational databases, specifying data modeling constraints that must be satisfied
  • Must analyze limitations: lack of relationships, restricted query patterns, and data modeling constraints that prevent certain applications

Student 2:Redis Deep Dive

Required Coverage:

  • Must explain Redis data structures (strings, hashes, sets, sorted sets, streams), analyzing design rationale for each structure and justifying when each is appropriate based on access patterns, not merely listing features
  • Must compare persistence models (RDB vs AOF), analyzing trade-offs in durability, performance, and recovery time
  • Must explain Pub/Sub and streams messaging patterns, comparing them with traditional message queues and identifying use cases
  • Must explain Redis Cluster and replication, analyzing how they provide high availability and identifying scaling limitations
  • Must evaluate Redis as a primary database, specifying durability and consistency guarantees and identifying scenarios where they are insufficient
  • Must analyze performance characteristics and memory management, identifying bottlenecks and optimization strategies

Student 3:DynamoDB Architecture

Required Coverage:

  • Must explain partitioning and hashing, specifying how partition keys determine data distribution and identifying hot partition problems
  • Must compare provisioned vs on-demand capacity, analyzing cost and performance trade-offs with quantitative examples
  • Must explain consistency models (eventual vs strong), specifying when each is used and analyzing performance implications
  • Must analyze global secondary indexes, explaining design constraints and limitations compared to relational indexes
  • Must evaluate cost-performance trade-offs, quantifying read/write unit costs and storage costs for different workload patterns
  • Must explain DynamoDB Streams and change data capture, specifying use cases and integration patterns

Student 4:Design Patterns & Pitfalls

Required Coverage:

  • Must explain at least three common patterns (session storage, leaderboards, rate limiting), analyzing design decisions behind each pattern and justifying why key-value stores are appropriate, not merely describing implementation steps
  • Must analyze hot partitions and scaling problems, explaining how to identify them and design strategies to avoid them
  • Must identify at least three data modeling anti-patterns, explaining why they fail and what alternatives exist
  • Must evaluate transaction support in key-value systems, specifying limitations and workarounds for applications requiring transactions
  • Must analyze migration strategies from SQL, identifying challenges and comparing approaches (big bang vs incremental), explaining failure risks and design trade-offs, not only listing migration steps
  • Must evaluate production considerations: monitoring strategies, backup approaches, and disaster recovery plans

Presentation Requirements

All presentations must be 17–20 minutes in duration and include the following components:

Note: Presentations that only summarize definitions, list features, or copy diagrams without interpretation will receive low marks. Each presentation must demonstrate analytical reasoning through comparisons, trade-off analysis, and justification of design decisions. Reading slides verbatim or presenting material that could be satisfied by reading documentation will be penalized.

Report Requirement: In addition to the presentation, each student must submit an individual PDF report. See Seminar Report Requirements for format, content, and submission details.

Evaluation Criteria

Criterion Weight Description
Technical Correctness 30% Accuracy of technical content, correct use of terminology, absence of errors
Depth of Understanding 25% Goes beyond surface-level definitions, demonstrates system-level comprehension
Clarity and Structure 20% Logical flow, clear explanations, appropriate use of examples and visuals
Use of Examples and Trade-offs 15% Concrete examples, discussion of limitations, comparison with alternatives
Slide Quality and Time Management 10% Professional formatting, appropriate pacing, stays within time limit

Recommended References

Books:

Documentation:

Academic / Technical: