Start with the decision#
A hot partition is a distribution failure, not simply high total load. Diagnose the key or range concentrating work before scaling the whole fleet.
Mechanism and state flow#
- Measure throttling, queueing, storage, and request rate per logical and physical partition.
- Identify whether heat comes from a low-cardinality key, a sequential range, or one genuinely popular entity.
- Increase key cardinality with a deterministic or random shard suffix when the access path can fan in.
- Isolate exceptional tenants or keys and split adaptive ranges before they exhaust shared capacity.
- Plan backfill, dual routing, and read merge before changing the key.
Concrete example#
Orders partitioned by today's date
All new orders land on one date key. The service adds a hash(order_id) modulo N suffix, writes each order to one predictable shard, and queries all N shards in parallel for daily reports.
Architecture consequence: Trade a single hot write partition for bounded read fan-in and keep N in versioned routing metadata.
Trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Calculated suffix | Reads know an item identity that can reproduce the shard. | Range queries still fan out across every suffix. |
| Random suffix | Only bulk retrieval matters and maximum write spread is useful. | Point lookup needs an index or fan-out. |
| Dedicated heavy-key path | A small number of known entities dominate traffic. | Routing and capacity policy become two-tiered. |
Failure diagnosis#
- Failure
- A key-salting change starts writing new shards while readers query only the old key.
- Impact
- Fresh records disappear from reads even though writes succeed.
- Detection
- Dual-read comparison shows count and version gaps during migration.
- Mitigation
- Version routing, dual read during backfill, verify parity, then retire the old path after the retention window.
- Trade-off
- Dual paths temporarily multiply cost and operational complexity.
Design checkpoint#
Work the scenario before revealing the checklist
- Name the hottest logical key and show its share of traffic.
- Choose deterministic or random sharding and calculate read fan-in.
- Design the routing-version migration and rollback.
- Set a per-key admission or isolation policy.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Is the hotspot logical or physical?
- Can this entity itself be split?
- How does re-sharding preserve read completeness?
- What happens when the shard count changes?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Designing partition keys to distribute workloadsAWS Documentation
- Using write sharding to distribute workloads evenlyAWS Documentation
Sources reviewed 2026-09-04. Service limits and product-specific guarantees still require current verification.