Zhivko Todorov
ALL CASE STUDIES

CASE 117 · TRUSS · 2023

DYNAMODBDAXCACHEREAD-HEAVY

DynamoDB reads cached in front, capacity dialled down behind.

A gaming backend ran a read-heavy DynamoDB table at provisioned 80k RCU. Most of the reads were repeated within a few seconds — game session state polled every 500ms. We put DynamoDB Accelerator (DAX) in front and dropped the RCU floor to 12k.

INDUSTRY

Gaming backend

DOMAIN

COST

DELIVERED

2023

STACK

DYNAMODB·DYNAMODB ACCELERATOR (DAX)·CLOUDWATCH METRICS·APPLICATION AUTO SCALING

RESULTS

What changed, by the numbers.

DYNAMO BILL

−71%

$31K → $9K / MONTH

DAX HIT RATE

94%

STEADY STATE

p99 READ LATENCY

−87%

4.2ms → 0.55ms

CODE CHANGES

DRIVER SWAP

NOTHING ELSE

HOW IT WENT

The polling pattern was the giveaway. Game sessions polled state every 500ms, but state changed every 5-30 seconds. So roughly 90% of the reads were re-reads of unchanged values, paid for at full DynamoDB read-capacity cost.

DAX is a write-through cache that sits in front of DynamoDB and serves repeated reads from memory. The application’s DynamoDB calls swap to the DAX SDK; the call signatures are the same. Cache TTL was set to 5 seconds, matching the lower bound of state changes.

Bill dropped 71% because the RCU floor fell from 80k to 12k — DAX absorbed most of the read traffic. p99 read latency improved 87% as DAX serves from memory in under a millisecond. Code changes were limited to the DynamoDB driver swap, no application logic touched.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →