One key gets all the traffic and throttles
“Table-level capacity graphs look fine, yet writes for one tenant, date, or product throttle; in Kafka one partition's consumer lag climbs while the others idle.”
THE PRINCIPLE
Throughput is per partition, not per table. A key that concentrates traffic caps the whole workload at one partition's limit.
FIRST MOVES
- Find the key: DynamoDB CloudWatch Contributor Insights (most throttled / most accessed keys), Kafka per-partition bytes-in and lag, Cassandra/Scylla per-partition metrics.
- Check the limit you hit: a DynamoDB partition serves up to 3,000 read units and 1,000 write units per second; item size counts against it.
- Avoid low-cardinality or time-ordered partition keys (status, today's date, tenant for a giant tenant); add a high-cardinality component.
- Write-shard hot keys with a calculated suffix (hash of an id mod N) so point reads still know where to look; queries fan out over N and merge.
- Absorb read-hot keys with a cache in front (DAX, Redis, CDN) instead of more partitions; in Kafka, key by the entity that needs ordering, not by tenant.
TOOLS: THEN → NOW
Raise provisioned capacity until throttling stopsContributor Insights to find the hot key, then fix the key design
Rely on burst capacity for spikesAdaptive capacity plus write sharding; adaptive capacity cannot exceed one partition's maximum
Partition by tenant or dateComposite keys with a hashed shard suffix, read with parallel fan-out
PATTERN SNAPSHOT
const SHARDS = 20;
function shardFor(id: string): number {
let h = 0;
for (const ch of id) h = (Math.imul(h, 31) + ch.codePointAt(0)!) >>> 0;
return h % SHARDS;
}
// Writes for one busy day spread over 20 partition key values.
await put({ pk: `2026-11-06#${shardFor(order.id)}`, sk: order.id, ...order });
// Point read: recompute the shard. Whole-day read: query all shards and merge.
const parts = await Promise.all(
Array.from({ length: SHARDS }, (_, i) => query({ pk: `2026-11-06#${i}` })),
);
const orders = parts.flat();CLOSE THE AI. EXPLAIN THIS.
Your table has 10x the write capacity it needs, but writes to one key still throttle. Why, and what changes fix it?RELATED SYMPTOMS
SOURCES
- Amazon DynamoDB: Best practices for designing partition keys (opens in new tab)Checked
- Amazon DynamoDB: Using write sharding to distribute workloads evenly (opens in new tab)Checked
- Amazon DynamoDB: Burst and adaptive capacity (opens in new tab)Checked
- Amazon DynamoDB: CloudWatch Contributor Insights, how it works (opens in new tab)Checked
Guide reviewed