Bird
Raised Fist0

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

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Clients

Send key-value read request

Client issues a GET request for a key

Protocol:WebSocket
BeforeClient holds the key to read but no data cached locally
AfterRequest sent to API Gateway over WebSocket
API Gateway

Forward request to Redis Cache

API Gateway checks Redis cache for the key

Protocol:Redis GET
BeforeAPI Gateway received client request, no cached data yet
AfterRedis Cache Cluster queried for key
Redis Cache Cluster

Cache lookup

Redis returns MISS for requested key

Protocol:Redis GET
BeforeKey not present in Redis cache
AfterCache miss detected, triggers fallback to DynamoDB
DynamoDB Store

Read key from durable store

DynamoDB returns the requested value

Protocol:DynamoDB GET
BeforeDynamoDB has the key-value data stored durably
AfterValue retrieved from DynamoDB for API Gateway
API Gateway

Update Redis cache and respond to client

API Gateway writes value to Redis and sends response

Protocol:Redis SET + WebSocket
BeforeAPI Gateway holds value from DynamoDB, Redis cache stale
AfterRedis cache updated; client receives value response
Data Replication & Backup

Replicate DynamoDB data

Data asynchronously replicated for durability

Protocol:Internal replication
BeforeDynamoDB data stored in primary region
AfterData replicated to backup regions for fault tolerance
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│    Clients    │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ Redis GET
        ▼
┌───────────────────┐
│ Redis Cache Clstr │
└───────┬───────────┘
        │ Cache Miss (Redis MISS)
        ▼
┌───────────────┐
│DynamoDB Store │
└───────┬───────┘
        │ DynamoDB GET
        ▼
┌─────────────────────────────┐
│Data Replication & Backup     │
└─────────────────────────────┘
Design Rationale

This architecture illustrates a typical key-value read request flow using Redis and DynamoDB. Clients send requests to the API Gateway, which first queries the Redis Cache Cluster for low-latency access. On a cache miss, the API Gateway falls back to DynamoDB, a durable NoSQL store, to retrieve the data. The retrieved value is then written back to Redis to optimize future reads. Data Replication & Backup ensures DynamoDB data durability and availability across regions. This design balances Redis's speed with DynamoDB's durability, highlighting trade-offs between caching and persistent storage in key-value systems.

Primary Focus

✓

Practice

(1/5)
1. In the request flow, at Step 4 the Delivery Worker checks the message queue's visibility timeout before processing. What happens if the visibility timeout expires before the message is acknowledged?
easy
A. The message is moved to a dead-letter queue without retry
B. The message is deleted immediately to prevent duplicates
C. The message is archived permanently without redelivery
D. The message becomes visible again and can be redelivered to another worker

Solution

  1. Step 1: Understand visibility timeout semantics

    Visibility timeout hides the message during processing; if not acknowledged, it reappears for redelivery.

  2. Step 2: Analyze options

    Immediate deletion (A) risks data loss; archiving without retry (C) prevents recovery; dead-letter queue (D) is for failed retries, not timeout expiry.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Visibility timeout expiry -> message reappears for retry [check]
Hint: Visibility timeout expiry -> message requeued for retry [check]
Common Mistakes:
2. A system must efficiently handle millions of concurrent calendar availability updates from hosts worldwide, ensuring low latency and eventual consistency. Which component is best suited to buffer and process these updates asynchronously?
easy
A. Use a relational database with strong ACID transactions for immediate consistency
B. Use a cache like Redis with TTL to store availability states temporarily
C. Use direct synchronous API calls to update availability in the main database
D. Use a distributed message queue like Kafka to decouple update ingestion from processing

Solution

  1. Step 1: Identify the need for asynchronous buffering

    Millions of concurrent updates require decoupling ingestion from processing to avoid bottlenecks.

  2. Step 2: Evaluate component suitability

    Relational DB (A) causes high contention and latency; Redis (C) is volatile and not durable; synchronous API calls (D) block and reduce throughput. Kafka (B) provides durable, ordered, and scalable buffering.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka buffers high-throughput writes asynchronously with durability [check]
Hint: Buffer high-write updates asynchronously with durable queues [check]
Common Mistakes:
3. Without Kafka in the chat system, what exactly breaks when Alice sends a message to Bob?
medium
A. Alice's message is immediately delivered but Bob's client cannot decrypt it
B. Alice's send blocks until Bob's server responds; if Bob's server crashes, the message is lost with no retry
C. Messages are duplicated because no deduplication queue exists
D. Alice's client crashes due to lack of message buffering

Solution

  1. Step 1: Understand Kafka's role in decoupling and durability

    Kafka buffers messages asynchronously, preventing blocking and enabling retries.

  2. Step 2: Trace failure without Kafka

    Without Kafka, Alice's server must synchronously contact Bob's server. If Bob's server is slow or crashes, Alice's send blocks or message is lost with no retry.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without Kafka, synchronous send blocks and loses messages on Bob's server crash [check]
Hint: No Kafka -> synchronous send blocks and loses messages [check]
Common Mistakes:
4. At 10x scale, which component in the real-time ML inference system is most likely to fail first and why?
hard
A. Model storage backend, due to increased read latency from large model files
B. Load balancer, since it cannot efficiently distribute traffic to a rapidly scaling number of servers
C. Kafka event stream, as partition count limits throughput and causes lag under heavy update load
D. Prediction API servers, because CPU-intensive model inference cannot be parallelized easily

Solution

  1. Step 1: Analyze scaling bottlenecks

    Model storage (A) scales with caching; Kafka (C) can be scaled by adding partitions; load balancers (D) scale horizontally.

  2. Step 2: Identify CPU bottleneck in inference

    Prediction API servers (B) perform CPU/GPU-bound inference; scaling is limited by hardware and model complexity, causing first failure under 10x load.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Inference servers hit CPU/GPU limits before storage or Kafka scale [check]
Hint: Inference servers hit CPU/GPU bottleneck before other components [OK]
Common Mistakes:
5. At 10x scale, which component is most likely to fail first due to the exact lookup requirement, and why?
hard
A. The backend database, because it cannot handle the increased exact lookup queries without Bloom filter filtering
B. The network layer, because increased traffic from exact lookups saturates bandwidth
C. The Bloom filter component, because its false positive rate grows linearly with scale, causing excessive backend queries
D. The cache layer, because it cannot store all keys for exact lookups at 10x scale

Solution

  1. Step 1: Understand Bloom filter scaling behavior

    Bloom filter false positive rate increases with scale unless filter size grows proportionally, causing more backend queries.

  2. Step 2: Analyze component failure likelihood

    Backend (A) fails eventually but Bloom filter inefficiency causes overload first. Network (C) and cache (D) are bottlenecks but secondary to Bloom filter false positive explosion.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Bloom filter false positives grow with scale, triggering backend overload first [check]
Hint: Bloom filter false positives grow with scale, overload backend first [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