5.Paying for What You Actually Use

A single "Flash Deal" listing goes viral in Singapore overnight — thousands of requests a second, all hitting one item, one partition key, while every other partition in the table sees completely ordinary traffic. The table's overall load looks fine on paper. That one partition doesn't.

Sarah realizes the real question was never "how much capacity does the table need" — it's "how much capacity does this one partition need, at its worst moment."

DynamoDB offers two real billing models, and they trade off differently. Provisioned capacity means GreenMart declares, ahead of time, how many reads and writes per second the table should handle — read capacity units and write capacity units — and pays for that reserved amount whether it's fully used or not, risking throttling if real traffic exceeds it. On-demand capacity is genuinely serverless: no capacity planning at all, DynamoDB scales automatically to whatever traffic actually arrives, billed per request — exactly the "Auto Scaling: ON" promise that made GreenMart stop wanting to run its own cluster in the first place.

On-demand doesn't erase capacity limits, though — it moves them from the whole table down to something more specific: a hot partition. Every partition, provisioned or on-demand, has its own real, physical throughput ceiling. When one partition key gets dramatically more traffic than the rest — like the viral flash deal — that one partition can throttle even while the table's overall capacity has plenty of room left. Partition distribution — spreading load evenly across partition key values — is the actual fix, the same underlying idea as Redis's hot keys and Cassandra's hot shards, DynamoDB's own version of a lesson this course keeps teaching in a new place each time.

DynamoDB does have one real, automatic mitigation: adaptive capacity, which detects an imbalanced partition and works to isolate and redistribute its excess load without GreenMart intervening manually. It genuinely helps — but it's a mitigation, not a design substitute. A partition key spread out enough that no single value dominates traffic in the first place is still the real fix, the same way this Act's very first chapter treated partition key choice as the most consequential decision on the table.

Cost modelling, concretely: this Act's own simulator has been reporting consumed capacity on every operation since the first chapter. A Query costing 1 unit versus a Scan for the same answer costing 20, multiplied by thousands of requests a day, is the real difference between a cheap table and an expensive one — the same Query-vs-Scan lesson from earlier in this Act, now with an actual number attached to what "expensive" means.