Posts

Showing posts with the label DynamoDB

DynamoDB Partition Key Design: Why Hot Partitions Kill Performance and How to Fix Them

You built a DynamoDB table, shipped it to production, and now reads are throttling under load — even though your provisioned capacity looks fine on paper. Nine times out of ten, the culprit is a poorly chosen partition key that funnels all traffic into a single physical partition. Understanding how DynamoDB partition keys work internally is the difference between a table that scales effortlessly and one that becomes a production incident at 2am. TL;DR: DynamoDB Partition Key Performance at a Glance Concern Key Point What is a partition key? The attribute DynamoDB hashes to determine which physical storage node holds the item What is a hot partition? A single partition receiving disproportionate read/write traffic, exhausting its per-partition throughput ceiling Why low-cardinality keys fail All items with the same key value land on the same partition — traffic concentrates regardless of total table capacity ...

LSI vs GSI in DynamoDB: Choosing the Right Secondary Index

You've modeled your DynamoDB table around one access pattern, and now a new query requirement has emerged — one that doesn't fit your primary key. Secondary indexes are the solution, but choosing between a Local Secondary Index (LSI) and a Global Secondary Index (GSI) has architectural consequences that are difficult to reverse. TL;DR — Quick Comparison Dimension LSI (Local Secondary Index) GSI (Global Secondary Index) Partition Key Same as base table Any attribute (can differ from base table) Sort Key Different attribute (required) Any attribute (optional) Creation Time At table creation only Any time (added/deleted dynamically) Consistency Strongly consistent reads supported Eventually consistent reads only Storage Scope Shares partition storage wit...

DynamoDB Capacity Modes: Provisioned vs. On-Demand — Which One Saves Money and Avoids Throttling?

Choosing the wrong DynamoDB capacity mode is one of the fastest ways to either over-pay for idle capacity or trigger throttling that cascades into application errors. TL;DR: DynamoDB Capacity Modes at a Glance Solution Mechanism Best For Complexity On-Demand AWS scales capacity automatically per request Unknown, spiky, or new workloads Low Provisioned (with Auto Scaling) You define RCU/WCU targets; Auto Scaling adjusts within bounds Predictable, steady-state workloads Medium Provisioned (manual) Fixed RCU/WCU; no automatic adjustment Tightly controlled, cost-sensitive workloads with known patterns High operational overhead Why DynamoDB Capacity Mode Selection Matters More Than You Think The decision isn't just about cost — it directly controls whether your table throttl...