Bird
Raised Fist0

Key-Value Stores - Redis vs DynamoDB, Use Cases, Trade-offs

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Key-Value Stores - Redis vs DynamoDB, Use Cases, Trade-offs
Comparing Redis and DynamoDB for key-value workloads with scale and latency trade-offs
mediumDatabases - NoSQLFreq: common
Prerequisites:Caching BasicsKey-Value Stores
⚙️
Functional Requirements
  • Store and retrieve key-value pairs with low latency
  • Support TTL-based expiration of keys
  • Provide strong or eventual consistency options
  • Support high throughput reads and writes (millions QPS)
  • Allow atomic operations on keys (increments, sets)
  • Enable horizontal scaling with minimal operational overhead
📊
Non-Functional Requirements
  • Handle 2 billion daily active users (DAU)
  • Support 99.99% availability SLA
  • Achieve 100ms P99 read latency under peak load
  • Scale to 925K writes per second (derived from DAU and usage)
  • Ensure data durability with multi-region replication
❓
Clarifying Questions to Ask
  • What is the expected read-to-write ratio for the workload?
  • Is strong consistency required or is eventual consistency acceptable?
  • What is the average and maximum size of the values stored?
  • Are TTLs fixed or variable per key, and what is the typical expiration duration?
  • Is multi-region replication required for disaster recovery?
  • What is the budget constraint for operational and storage costs?
Out of Scope
✗ Complex relational queries or joins
✗ Full-text search capabilities
✗ Multi-tenant data isolation beyond basic namespaces
✗ Real-time analytics or OLAP workloads
📌
Assumptions
  • 2 billion DAU
  • 40 key-value writes per user per day
  • Average value size 100 bytes
  • Read-to-write ratio 10:1
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 writes/sec
peak write qpsAssuming 2× peak factor → 1,851,852 writes/sec
read qpswrite_qps × 10 = 9,259,260 reads/sec
peak read qpsAssuming 2× peak factor → 18,518,520 reads/sec
💾
Storage Estimate
daily storage gb(2B × 40 × 100 bytes) / (1024³) ≈ 7.45 TB/day
retention days7
total storage gb7.45 TB × 7 = 52.15 TB
with replication52.15 TB × 3 replicas = 156.45 TB
🖥️
Server Estimate
redis cluster nodesAssuming 100K writes/sec per node → 20 nodes for writes
dynamodb capacity unitsProvisioned 2M write capacity units and 20M read capacity units
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |   Clients   |
          +------+------+
                 |
        +--------v---------+
        |  API Gateway     |
        +--------+---------+
                 |
    +------------+-------------+
    |                          |
 +--v---+                  +---v---+
 | Redis |                  |DynamoDB|
 | Cache |                  |  Store |
 +--+----+                  +---+----+
    |                           |
    |                           |
 +--v---------------------------v---+
 |       Data Replication & Backup   |
 +-----------------------------------+
🧩
Components
API Gateway
Entry point for client requests, routes to Redis or DynamoDB based on use case
Why thisCentralizes request routing and authentication, supports rate limiting and metrics using technologies like AWS API Gateway or Kong
Why notDirect client access to DBs increases attack surface and complicates scaling; lacks centralized auth and monitoring
Redis Cache Cluster
In-memory key-value store for low-latency, high-throughput reads and writes with TTL support
Why thisRedis supports sub-millisecond lookups, native TTL expiration, atomic ops, and pub/sub; Redis Cluster enables horizontal scaling
Why notMemcached lacks native TTL and atomic operations; Redis Cluster scales better and supports persistence
DynamoDB Store
Durable, fully managed NoSQL key-value store for persistent storage with multi-region replication
Why thisDynamoDB scales to millions QPS with built-in replication, offers strong consistency option, and serverless operations
Why notCassandra requires manual cluster management and tuning at this scale; DynamoDB reduces operational overhead
Data Replication & Backup
Ensures durability and disaster recovery by replicating data across regions and backing up snapshots
Why thisDynamoDB global tables and Redis AOF/RDB backups provide multi-region durability and recovery
Why notManual replication with custom scripts risks data loss and operational complexity
Clients
Mobile/web apps or backend services interacting with the key-value store via API Gateway
Why thisClients abstracted from storage details, enabling flexibility and security
Why notDirect DB access from clients exposes credentials and complicates schema evolution
🔄
Data Flow
1
Clients → API Gateway
Send key-value read/write requests
API Gateway authenticates and routes requests
2
API Gateway → Redis Cache Cluster
Route reads and writes for hot keys or low-latency needs
Redis handles sub-millisecond TTL and atomic ops
3
API Gateway → DynamoDB Store
Route writes and reads for durable, persistent storage
DynamoDB provides strong consistency and multi-region replication
4
Redis Cache Cluster → Data Replication & Backup
Persist snapshots and append-only files for durability
Ensures Redis data durability despite in-memory nature
5
DynamoDB Store → Data Replication & Backup
Replicate data across regions and backup snapshots
Supports disaster recovery and high availability
6
Clients → API Gateway
Receive responses for read/write operations
API Gateway aggregates and returns results

Practice

(1/5)
1. In a system trace, at step 4 the circuit breaker checks the failure count before forwarding a request. What happens if the failure count exceeds the threshold at this step?
easy
A. The circuit breaker opens and immediately returns an error without calling downstream
B. The request is forwarded but logged for monitoring
C. The circuit breaker retries the request twice before opening
D. The request is queued until the downstream service recovers

Solution

  1. Step 1: Trace circuit breaker decision at Step 4

    When failure count exceeds threshold, the circuit breaker transitions to OPEN state and stops forwarding requests.

  2. Step 2: Understand behavior on open circuit

    Requests are immediately failed (B), not forwarded (A), retried (C), or queued (D).

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Open circuit returns error immediately without downstream call [check]
Hint: Open circuit returns error immediately, no downstream call [OK]
Common Mistakes:
2. In a code repository system, which component is best suited to efficiently store and retrieve file diffs to minimize storage space while allowing fast access for merges?
easy
A. Use a relational database with BLOB columns to store entire file versions
B. Use a distributed cache like Redis to store diffs temporarily for quick access
C. Use a content-addressable storage system that stores objects by hash and reuses identical content
D. Use a simple file system directory structure with full copies of each file version

Solution

  1. Step 1: Identify storage needs for diffs

    Storing diffs efficiently requires deduplication and immutability; content-addressable storage (CAS) stores objects by their hash, enabling reuse of identical content and saving space.

  2. Step 2: Evaluate other options

    Relational DB with BLOBs stores full versions, wasting space; Redis is volatile and not durable for persistent storage; file system copies waste space and slow for merges.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    CAS stores objects by hash -> deduplication and fast retrieval [check]
Hint: Content-addressable storage deduplicates by hash [check]
Common Mistakes:
3. For a chat application requiring low latency message delivery but tolerating occasional message loss, which architecture best balances latency and throughput?
medium
A. Use a batch processing system that aggregates messages every 5 seconds
B. Use a synchronous request-response system with guaranteed delivery acknowledgments
C. Use an asynchronous message queue with at-least-once delivery and eventual consistency
D. Use a distributed cache with write-through persistence for all messages

Solution

  1. Step 1: Analyze latency vs throughput needs

    Batch processing adds latency but can increase throughput and tolerate some message loss.

  2. Step 2: Evaluate architectures

    Synchronous (A) increases latency; asynchronous queue (B) reduces latency but may cause duplicates; distributed cache (D) lacks delivery guarantees; batch (C) balances throughput with acceptable latency for some use cases.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Batching trades latency for throughput, tolerating some loss [check]
Hint: Batching trades latency for throughput and tolerates loss [check]
Common Mistakes:
4. If the centralized session store is unavailable, what exactly breaks in a system where stateless frontends rely on it for user session data?
medium
A. Frontend servers crash due to missing session data causing system-wide outage
B. User requests block waiting for session data, causing increased latency and possible timeouts
C. User sessions silently expire but requests continue processing without authentication
D. Load balancer reroutes all traffic to a backup session store automatically

Solution

  1. Step 1: Identify session store role

    Centralized session store provides authentication and session state to stateless frontends.

  2. Step 2: Trace failure impact

    If unavailable, frontends cannot validate sessions, leading to silent session expiry and unauthenticated request processing.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Session store down -> sessions expire silently, requests proceed unauthenticated [check]
Hint: Session store down -> silent expiry, unauthenticated requests proceed [check]
Common Mistakes:
5. Without a distributed lock service, what exactly breaks when two instances concurrently update a shared configuration in a distributed system?
medium
A. Both updates succeed but the system crashes due to race conditions
B. One update overwrites the other silently, causing inconsistent configuration state
C. The system automatically queues updates and applies them sequentially
D. Updates are rejected by the database due to conflicting transactions

Solution

  1. Step 1: Understand lack of distributed locking

    Without distributed locks, concurrent updates can overwrite each other silently (B), causing inconsistent state.

  2. Step 2: Evaluate other options

    System does not automatically queue updates (C) without explicit coordination. Database rejecting conflicting transactions (D) depends on isolation level and may not prevent lost updates. System crash (A) is unrelated.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Concurrent updates without locks -> silent overwrite [check]
Hint: No lock -> silent overwrite, no automatic queuing [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard