analytics
Trending Counter
One hot count, spread across shards so no single key takes the load.
A counter everybody increments at once is a single item, and a single item lives on a single partition with a hard ceiling on writes. Splitting it into N shards turns one hot key into N warm ones; reading it back means summing them.
The model
TrendShard
One slice of a topic's count, on a partition of its own.
- pk
- TREND#<topic>#<shardId>
Attributes: count (N), updatedAt (N)
Access patterns
- GetItemRead one shard
One shard's count. A total needs one of these per shard.
- UpdateItemIncrement a shard
ADD one to a shard chosen at random.
Design notes
A single item is a single partitionwhy
Every write to one partition key lands on one partition, and a partition has its own write ceiling no matter how much capacity the table has. A counter everyone increments is therefore not slow because DynamoDB is slow, it is slow because you gave it one place to go. Note where the shard has to sit: in the partition key. Putting it in a sort key produces the same four rows and the same total, on the same single partition, with none of the headroom - a design that looks sharded and is not.
The shard count is a decision you have to live withtrade-off
Four shards means four times the write headroom and four reads to get a total. More shards raise the ceiling and make every read more expensive; fewer make reads cheap and put the ceiling back. Worse, changing N later re-homes every future write while the old counts sit under the old keys, so the number is easier to choose carefully than to revise.
The total is the application's jobtrade-off
Each shard is its own partition, so there is no single read that returns them all - a total is four reads and an addition in the caller. That is the price of the write headroom, and it is why this pattern suits things that tolerate approximation, like a mentions count, and suits money badly. Nothing makes the four reads a consistent snapshot: shards you read early can be incremented before you finish.
Look at the quiet topictrade-off
quiet-topic has four rows holding four, and two of them are zero. That is the cost side of the design: every topic pays for N rows and N reads whether or not it is busy. Sharding earns its place only where the write rate actually needs it, which is why real systems shard the hot keys and leave the rest alone.
Incrementing is a design here, not a live demonstrationtrade-off
The engine performs atomic ADD correctly, but the resolver templates writes without emitting them as runnable, so the console reads the shards rather than racing writers across them. The read half - the scatter, without the gather - is what this page can show.
Taught in the course
- UpdateItem edits in place - UpdateItem changes named attributes and can increment a counter atomically.
One shard's count. A total needs one of these per shard.
Run an operation to see the raw engine response.
The in-browser engine is a preview build. Transactions, vector search, streams, tags and TTL are among the operations it doesn't implement yet.