# Redis vs DynamoDB

> Choose Redis for memory-resident caching, counters, and operations on structures such as sorted sets; choose DynamoDB for durable, managed key-value and document storage. They often work together: DynamoDB holds authoritative records, while Redis accelerates reads or maintains rebuildable state.

Source: https://sysround.com/compare/redis-vs-dynamodb
Updated: 2026-11-05


## Side by side

| | Redis | DynamoDB |
|---|---|---|
| Primary role | Redis: fast, memory-resident state and caching | DynamoDB: durable, managed application storage |
| Data operations | Strings, hashes, sets, sorted sets, scripts | Items, key queries, indexes, conditional writes |
| Latency | Low-latency in-memory operations; network still matters | Service request latency; depends on operation and workload |
| Durability | Depends on persistence and replication configuration | Built-in durable storage across availability zones |
| Consistency | Primary reads see applied writes; replicas can lag | Eventual or strong reads on tables; GSIs are eventual |
| Scaling | Cluster shards keys; multi-key operations have constraints | Managed partitioning; key design and hot keys still matter |
| Expiration | Expired keys become inaccessible; cleanup is active and lazy | TTL deletion is asynchronous; applications must check expiry |
| Cost drivers | Provisioned memory, replicas, and operational overhead | Reads, writes, storage, indexes, and replication |

## The differences that matter

The first decision is whether losing acknowledged state is acceptable. Redis supports snapshots and append-only persistence, so it is not simply a cache, but persistence settings and asynchronous replication affect recovery and possible data loss. DynamoDB is usually the simpler default for authoritative records when its access model fits.

Redis provides server-side operations on counters, sets, hashes, and sorted sets. A script can atomically check and update a rate-limit bucket, but in Redis Cluster its keys generally need to share a hash slot. DynamoDB supports atomic item updates, conditional writes, and bounded multi-item transactions, but it does not offer Redis-style sorted-set operations.

Both need a plan for hot keys. Adding Redis shards does not split one hot counter across them, and DynamoDB's managed scaling does not make an arbitrarily hot item unlimited. Sharding counters or spreading a tenant across partition keys increases throughput at the cost of aggregation work and potentially weaker coordination.

Expiration has different application consequences. Redis treats an expired key as absent on access, though memory cleanup is not instantaneous. DynamoDB TTL performs background deletion and can leave expired items present for days, so a session, lease, or hold must be rejected based on its stored expiration time rather than whether the item still exists.

Using both introduces a consistency boundary. With cache-aside, write the authoritative record to DynamoDB and invalidate or refresh Redis, then explain how concurrent reads and failed invalidations can produce stale values. Protect DynamoDB against cache outages and cold starts with request coalescing, bounded retries, and admission control.

## Choose Redis when

- You need a cache whose contents can be rebuilt, and the useful working set fits your memory budget.
- You need atomic, low-latency operations for rate-limit buckets, counters, or short-lived coordination state, with an explicit failover policy.
- You need sorted-set operations for live rankings or time-ordered membership rather than only key-based item retrieval.
- You can operate Redis or use a managed offering, and you have defined persistence, eviction, replication, and recovery behavior.

## Choose DynamoDB when

- You need durable application records without operating database servers or managing Redis persistence yourself.
- Your access patterns fit partition-key lookups, sort-key ranges, and a small set of planned secondary indexes.
- You need conditional updates or transactions to enforce durable invariants such as unique claims or state transitions.
- You want independently scalable storage and request capacity, and can design around hot partitions, throttling, and request-based costs.

## Worked example: A URL shortener with a hot redirect path

Suppose a URL shortener stores 200 million mappings and serves 100,000 redirects per second at peak. DynamoDB can hold the authoritative code-to-URL records, while Redis caches frequently requested mappings. With an assumed 95% cache hit rate, DynamoDB receives roughly 5,000 mapping reads per second instead of 100,000, excluding retries and other traffic. But a cold cache can push the full read load downstream, so the design needs load shedding, request coalescing, and a capacity plan. If links can be disabled immediately, cached redirects need a revocation strategy; a long TTL alone is not sufficient. Redis is an optimization here, not the only copy of the mappings.

## In the interview

- Start with the invariant: can this state disappear, become stale, or be reconstructed? Distinguish a cached seat display from the authoritative reservation before naming either technology.
- Estimate item size, working-set size, peak reads and writes, and key skew. The interviewer may ask whether memory capacity, a hot item, or downstream traffic during a cache miss is the actual limit.
- Name the exact atomic operation. For Redis, explain script scope and cluster hash slots; for DynamoDB, explain the condition expression or transaction and how retries remain idempotent.
- State the consistency mode and read path. A strong DynamoDB table read does not make a global secondary index or a Redis cache strongly consistent, and Redis replica reads can lag.
- Walk through failure: Redis failover or eviction, DynamoDB throttling, and total cache loss. Explain whether you reject requests, serve stale data, or allow a controlled amount of incorrect behavior.

## Common mistakes

- Calling Redis nonpersistent, or assuming that enabling persistence guarantees no acknowledged writes can be lost during failover.
- Treating DynamoDB TTL as a precise timer for session revocation, seat release, or lease expiration.
- Assuming either product automatically solves a hot key, or that adding capacity makes every operation proportionally faster.
- Adding Redis without defining cache invalidation, stale-read tolerance, and protection against a cache stampede.

## Interview questions where it comes up

- [Design a URL shortener like Bitly](https://sysround.com/questions/design-url-shortener): Separate durable short-code mappings from hot redirect caching, including invalidation and cold-cache overload.
- [Design a distributed rate limiter](https://sysround.com/questions/design-rate-limiter): Compare Redis scripts with DynamoDB conditional updates while explaining atomicity, hot keys, latency, and failure policy.
- [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Distinguish cached availability and expiring coordination state from durable, conditional reservation updates.
- [Design a distributed cache](https://sysround.com/questions/design-distributed-cache): Redis makes memory limits, eviction, sharding, and replica failover concrete, while DynamoDB illustrates a backing-store role.
- [Design a top K trending system](https://sysround.com/questions/design-top-k): Redis sorted sets support live rankings, while durable events or records provide the basis for rebuilding lost ranking state.
- [Design a login and authentication system](https://sysround.com/questions/design-authentication-system): Session storage exposes the trade-offs among fast lookups, durable revocation, expiration checks, and stale cached authorization state.

## FAQ

### Is Redis faster than DynamoDB?

Redis is designed for low-latency in-memory operations and is often chosen for the fastest serving path. Actual end-to-end latency depends on network placement, connection reuse, payload size, command complexity, and load. Compare the required operation and tail-latency target rather than claiming a universal speed ratio.

### Can Redis replace DynamoDB as the primary database?

It can for workloads whose data model, memory footprint, and recovery requirements fit Redis. You must explicitly choose persistence, replication, backups, and an eviction policy that does not discard authoritative data. DynamoDB is generally the more straightforward choice for durable key-value records when its query model fits.

### Should I use Redis in front of DynamoDB?

Use it when repeated reads, expensive derived results, or Redis-specific operations justify another stateful component. First check whether direct DynamoDB reads already meet the latency and cost requirements. If you add Redis, define staleness limits, invalidation behavior, and how the system survives cache loss.

## Related concepts

- [Caching strategies](https://sysround.com/concepts/caching-strategies)
- [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys)
- [Cache invalidation](https://sysround.com/concepts/cache-invalidation)
- [Partitioning strategies](https://sysround.com/concepts/data-partitioning)
- [Database replication](https://sysround.com/concepts/replication)


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.