CASE 117 · TRUSS · 2023
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.
Gaming backend
COST
2023
RESULTS
What changed, by the numbers.
DYNAMO BILL
−71%
DAX HIT RATE
94%
p99 READ LATENCY
−87%
CODE CHANGES
DRIVER SWAP
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.
RELATED · SAME DOMAIN
Other engagements in this space.
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.