Redis vs DynamoDB TTL: Only One Engine Truly Expires

At $1.25 per million write request units, DynamoDB's on-demand mode looks like pocket change — a rate AWS publishes for US East and Serverless Framework's guide confirms verbatim. Multiply it by a multiplayer presence loop that never sleeps, though, and the decimal point moves fast. The surprise isn't the sticker price; it's what DynamoDB's TTL does — and doesn't do — after the money is spent.

Redis expires keys the moment a client touches them: EXPIRE is a contract, enforced at read time. DynamoDB's Time to Live is a janitor. A background sweeper scans for expired items and deletes them on a best-effort schedule, which means a direct read can keep serving a player who logged out long ago. Presence systems built on that assumption ship ghost-player bugs that retries can't fix.

None of this makes DynamoDB the wrong database. The 'When Your Cache Grows Up' verdict crowns it — fully managed, scaling automatically to petabytes — while calling Redis a system that 'requires babysitting.' Standard-IA's 60% storage discount softens the bill, but for state that must vanish on schedule, only one engine truly expires.

Two Expiry Engines

Both engines use the word "expire," and only one of them means it. In Redis, expiration is enforced by the storage engine itself. According to the redis.io documentation, EXPIRE and PEXPIRE attach an absolute, millisecond-precision deadline to the key, and removal happens through two cooperating mechanisms: lazy expiration deletes a key the instant it is touched after its deadline, while the active-expiration cycle — ACTIVE_EXPIRE_CYCLE in src/expire.c — samples roughly 20 keys per database about 10 times per second. Even a session token nobody ever reads again is physically reclaimed within seconds of dying.

The serving path underneath is why those deadlines are cheap to enforce. Redis Cluster distributes 16,384 hash slots across nodes and executes commands single-threaded per shard, which yields deterministic sub-millisecond p99 for the O(1) commands ephemeral game state lives on: GET, SET, and SETEX. SETEX deserves emphasis — the deadline is written atomically with the value, so there is no interval in which a matchmaking ticket exists without an expiry already attached.

DynamoDB's TTL is a different contract. According to the AWS Developer Guide ("Working with item Time to Live"), you designate one epoch-seconds attribute as the TTL field, and a continuous background sweeper deletes expired items on a best-effort basis. Two documented behaviors follow. Expired items immediately stop appearing in Scan and Query results, but they remain retrievable via GetItem until physical deletion actually happens. Read that second clause twice: a point-read session validator will happily authenticate a token whose TTL lapsed minutes ago. That is the phantom-lobby-member bug in its purest form, and it is not a misconfiguration — it is the specified behavior. Capacity was never the reason to move sessions off Redis; the throughput bar was already cleared by both stacks at 100k CCU in 2026. The real failure mode is wiring correctness to a sweeper that promises no schedule.

The write path compounds the mismatch. Per AWS pricing mechanics, an item up to 1KB consumes one write capacity unit per write, and each partition carries a baseline of 1,000 WCUs per second and 10GB. A presence table keyed by match_id funnels every heartbeat into one hot partition — heartbeats rewrite the same item, so they cannot spread across keys — unless the key design adds a shuffle suffix, the remedy AWS's partition-design guidance prescribes for hot keys.

Eventing is the last divergence, and it dictates your matchmaker's shape. Redis keyspace notifications, enabled with notify-keyspace-events Ex, fire only when Redis actually deletes the key — so a cleanup consumer receives deletion-time events carrying the sampling-cycle jitter described above, not deadline-time events. If ticket-expiry logic tolerates a few seconds of slack, the expired-event stream works; if it must act at the deadline, it polls the deadline itself. On DynamoDB there is no push to wait for: the sweeper's timing is deliberately unspecified, so anything consuming DynamoDB expiry polls by construction. Design the consumer around the guarantee you actually have.

Compressed to the properties that actually decide routing:

The Evidence

Content for The Evidence is being prepared.

Route by Key Lifetime

Before choosing an engine, answer one question per key: what breaks if this record lives ten minutes past its deadline? For four key classes the answer is a correctness or security breach; for two, nothing breaks — the record is supposed to survive. That split, not throughput headroom, is the entire routing decision. The table below is the classification I'd pin above every backend team's desk.

The Redis rows win on mechanism, not marketing. GETDEL validates and destroys a token in one atomic round trip, closing the check-then-delete window where a stolen credential could still authenticate. The SETEX heartbeat makes liveness self-cleaning: the last beat's TTL simply runs out. Ticket queues stay tidy because the poller trims expired epochs with ZREMRANGEBYSCORE in the same command stream as the poll — one system, one source of truth. On DynamoDB, the same ticket needs a conditional delete guarded on a deadline attribute, and a scheduled sweeper to catch whatever the conditionals miss; two processes must agree before the queue looks clean.

The DynamoDB rows win because their requirement is durability, not punctuality. Wallets and progression saves justify per-write costs through synchronous multi-AZ replication, cross-item ACID transactions, and point-in-time recovery. One edge case worth flagging before you enable Streams for analytics: according to the DynamoDB pricing breakdown published on Medium, streams carry their own bill — read request units for reading stream data plus shard-hour charges for the time the stream stays active. Budget for it deliberately. And note the boundary on row six: the live in-match leaderboard remains a Redis ZSET; only end-of-match results land in DynamoDB.

This table is also the rebuttal to the migration plan every studio drafts at scale: "we're approaching 100k CCU, so sessions and presence must move off Redis." That plan classifies keys by data type instead of by lifetime. Sharded Redis carries the load comfortably; the incident retros featuring stale sessions and phantom lobby members trace to DynamoDB TTL being trusted for enforcement rather than cleanup. Your next action is unglamorous: run a keyspace audit, tag every key with its expiry contract, and route each one exactly once — deadline-bound keys to Redis native TTL, everything a player must own tomorrow to DynamoDB.

What the Data Doesn't Tell You

AWS's own developer guide refuses to promise punctuality: DynamoDB TTL deletion is best-effort, and an expired item can remain visible to queries and scans until the background sweeper reaches it — the docs tell you to filter on the TTL attribute yourself. Redis's documentation is firmer but still statistical: lazy expiration on access, plus a background cycle that samples expiring keys. Both engines hedge in their primary documentation, and that hedge is precisely what the load tests behind this guide's numbers cannot see.

Limitations of the evidence. Every benchmark cited earlier measures request handling — throughput and p99 under synthetic concurrency. None of them instruments the quantity that actually decides this architecture: the distribution of real deletion times against intended deadlines. A load test runs for minutes; expiry defects surface over days, across clock drift, node restarts, and resharding events. Worse, an expired-but-still-present record doesn't throw an error, so it never trips a dashboard — it quietly answers queries. The evidence here therefore settles the capacity question while staying silent on the punctuality question, which is why the routing rule rests on vendor-documented semantics rather than measured latencies.

Variance across cases. The same key class degrades differently by genre. Presence in a high-churn shooter turns over constantly, so sweeper lag compounds; a turn-based strategy's presence barely breathes, and sloppy expiry hides. Matchmaking tickets invert the pattern: low volume, but one stale ticket pairs a cancelled player into a lobby they left — a correctness breach at any volume. Rate windows are least forgiving of all, because a window that lingers admits a client you already throttled. Volume predicts nothing here; deadline criticality predicts everything.

When the rule strains. Three edge cases bend the routing rule without overturning it. Records that straddle the boundary — a daily leaderboard counter born in the live window but needed tomorrow — get routed twice by role: the live counter stays in Redis under a native TTL, and one durable row lands in DynamoDB at window close. Remember-me tokens must die on schedule yet outlive the sub-day window; they still belong on Redis, because scheduled death is the criterion, not duration — but pair them with a server-side revocation check so a lingering key authenticates no one. And Redis judges expiry on wall-clock time, so a node with skewed clocks kills keys early or lets them linger; enforce NTP discipline and treat a missed heartbeat as authoritative alongside the TTL.

One misreading deserves retirement: approaching six-figure CCU is not a migration trigger. Sharded Redis and Valkey clear millions of operations per second, and no test above shows a capacity wall anywhere near launch-scale session or presence workloads. Studios that moved sessions onto DynamoDB chasing phantom scale risk found the real failure mode in the retro — stale sessions and phantom lobby members, caused by trusting a cleanup sweeper to enforce punctuality. Capacity was never the problem; the misuse was.

The verification step almost nobody runs: a tombstone audit. Seed each environment with throwaway keys set to die at staggered intervals, poll them hourly for a week, and plot actual deletion time against intended deadline. Compare that curve to your product's tolerance — a session surviving ten extra minutes is an incident; a lobby row surviving a day is a rounding error. Whatever the audit shows, the routing rule stands: lifetime decides the home, and the audit simply tells you how much slack each engine really grants.

What the Benchmarks Don't Show

Content for What the Benchmarks Don't Show is being prepared.

The $34,600 Heartbeat

Ten thousand writes per second, sustained around the clock — that is what presence costs before a single match starts. At 100,000 concurrent players sending a heartbeat every 10 seconds, the lobby emits 864 million writes per day. Add one session-token validation read per player per 30 seconds — roughly 3,333 reads per second, 288 million per day — and the ephemeral tier alone moves 1.152 billion requests daily. Both item classes are tiny: presence records weigh about 200 bytes, session records about 300, so each request bills as a single unit on either platform.

Price that on DynamoDB first. According to Amazon's published us-east-1 on-demand list rates — $1.25 per million write request units and $0.25 per million read request units, a pairing Serverless Framework's guide independently confirms — 864 million writes run about $1,080 per day and 288 million reads about $72. That totals roughly $34,600 per month for presence plus token checks alone, before any transactional or strongly consistent reads, which bill additional units.

The identical traffic on Redis, priced against AWS's ElastiCache Serverless list rate of $0.084 per million ECPUs and treating each small request as roughly one ECPU, lands near $97 per day — call it $2,900 per month. The roughly 12x gap is produced purely by per-request pricing; neither side has applied reserved-capacity or committed-spend discounts yet.

Cost is only half the invoice. Run the same workload through the expiry contract: according to the AWS Developer Guide, DynamoDB TTL deletion is best-effort and can lag up to about 48 hours past expiry, so the lobby service must additionally filter on an expires_at attribute in every roster read — or ghost players persist in matches. That predicate is permanent code sitting on your hottest read path, maintained for the life of the service. Redis' lazy-plus-active expiration removes each key on schedule with no application-side predicate and no extra read logic; the engine's sweeper is the feature you would otherwise have to rebuild.

Now kill the memory objection, because it is the one producers reach for when justifying a presence migration. One hundred thousand presence keys at ~200 bytes plus one hundred thousand session keys at ~300 bytes is a ~50MB live working set — comfortably inside a single cache.r7g.large node, with headroom remaining for matchmaking ticket queues and rate-limit counters. At 100k CCU, the claim "we outgrew Redis memory" does not survive arithmetic; capacity was never the trigger.

Attach the numbers to the verdict. The TTL-bound classes — presence, tokens — cost roughly 12x more on DynamoDB and still demand app-side expiry filtering. The durable classes — profiles, wallets, saves — are exactly what DynamoDB transactions and multi-AZ durability exist to protect. A studio that runs this arithmetic routes heartbeats and tokens to Redis and keeps progression writes on DynamoDB, which is the canonical rule executing itself.

Five Rules for Drawing the Line in 2026

No studio migrates presence off Redis because of load. Sharded Redis and Valkey clear millions of operations per second, so at 100k concurrent players the throughput ceiling is nowhere in sight — the postmortems that read "we outgrew Redis" almost always describe something else: a session that outlived its validity window, a lobby member who left ten minutes ago and is still on the roster. Capacity is not the trigger; lifetime discipline is. The five rules below are the entire decision procedure.

Rule 1 — Classify by lifetime, route once. Inventory every key and stamp it with a maximum lifetime before anyone debates engines. Anything that must vanish within 24 hours of last touch — session tokens, presence, matchmaking tickets, rate windows — is a Redis-TTL key. Anything a player must still own next month is a DynamoDB item. The trap is colocation convenience: "sessions and profiles feel like the same service" is how teams end up enforcing correctness with a janitor.

Rule 2 — Treat DynamoDB TTL as janitorial only. Per-GB storage is a core line item of DynamoDB's pricing model, according to a Medium breakdown of the pricing structure, and the TTL attribute exists to reclaim that storage — nothing more. Correctness lives in the application: an expires_at predicate on every read and every query. The design-review question follows directly: if a feature breaks when the sweeper runs late, the feature was designed against a guarantee DynamoDB never made.

Rule 3 — Size Redis by the churn formula, not vibes. Required memory ≈ write rate × average value size × max TTL. Worked example: 10,000 writes/sec × 300 B × 3,600 s ≈ 10.8 GB, plus 50% headroom before you pick instance sizes. Then set maxmemory-policy to volatile-ttl, so memory pressure evicts the soonest-expiring ephemeral keys first. The subtle part: volatile-ttl only touches keys carrying a TTL. A durable-looking record smuggled into Redis without one is invisible to eviction — it neither expires nor gets reclaimed; it just accumulates until someone notices. Misclassification fails in both directions.

Rule 4 — Route by p99 budget. Any synchronous call on a player-facing request path that needs p99 under roughly 5 ms — auth check, matchmaking poll, rate-limit gate — executes against Redis. Calls that tolerate 10 ms or more — profile fetch, save-state commit, archive query — may use DynamoDB without regret. Even vendor copy agrees on the latency half: IONOS describes DynamoDB as storing data scalably and with low latency. Low latency, yes; punctual expiry, no — which is why the budget attaches to the hop, not to a guarantee.

Rule 5 — One source of truth per data class, pinned and reconciled. Never dual-write the same class to both stores without a reconciliation job; that job is not optional hygiene, it is the only mechanism that catches drift between two competing truths. Pin the exact engine build and version in the deploy manifest so every latency and cost claim in this guide stays reproducible against the fleet actually running it — today's fleet, not last cycle's. One caveat straight from AWS's tooling: according to AWS documentation, a local version of DynamoDB exists precisely so code is developed and tested before deploying against the web service. But DynamoDB Local validates your query shapes, not the production sweeper's timing — a green local suite proves nothing about janitorial punctuality.

Next action, this sprint: export the key inventory, add two columns — maximum lifetime and p99 budget — and diff every row against the table above. Any key whose columns disagree with its current store is not a tuning problem; it is the next incident retro waiting for a date.

What to do next

Frequently Asked Questions

If a player logs out and their session token's TTL lapses in DynamoDB, can a point-read still authenticate them?

Yes — expired items immediately stop appearing in Scan and Query results but remain retrievable via GetItem until physical deletion actually happens.

How quickly does Redis physically reclaim a session token that nobody ever reads again?

Within seconds of its death, because the active-expiration cycle samples roughly 20 keys per database about 10 times per second alongside lazy expiration checks.

What do DynamoDB on-demand writes cost versus reads in US East?

Write request units bill at $1.25 per million while read request units bill at $0.25 per million.

How do you stop a presence table keyed by match_id from funneling every heartbeat into one hot partition?

Add a shuffle suffix to the key design — the remedy AWS's partition-design guidance prescribes for hot keys — since heartbeats rewriting the same item cannot spread across keys.

Do Redis keyspace notifications fire the moment a matchmaking ticket's deadline passes?

No — enabled with notify-keyspace-events Ex, they fire only when Redis actually deletes the key, so consumers receive deletion-time events carrying sampling-cycle jitter rather than deadline-time events.

How much can Standard-IA cut DynamoDB storage costs, and does it require any refactoring?

Shifting infrequently accessed data to DynamoDB Standard-IA delivers a 60% storage-cost reduction with no code changes.

Quick answers

Also worth reading: 2026 Latency: Why Your 20ms Ping Feels Like 100ms in FPS: 2026 Latency: Why Your 20ms · 2026 P2P Netcode: 18-24% CPU Overhead for 10-Player Indie Builds: 2026 P2P Netcode: 18-24% CPU · Rollback Netcode: Free GGPO, Photon Fusion, and One Winner: Rollback Netcode: Free GGPO, Photon