Start with the decision#
Write capacity is constrained by the narrowest serialization point: one partition, lock, index, synchronous replica set, or downstream side effect. Find that point before adding queues or shards.
Mechanism and state flow#
- Measure accepted commands separately from durable commits and completed side effects.
- Choose a partition key that spreads writes while keeping required atomic state together.
- Batch or append where the product permits delayed materialization; keep admission and idempotency at the edge.
- Use a durable queue to absorb bursts only when backlog age and retry semantics are acceptable.
- Scale consumers and storage partitions from queue age, partition utilization, conflict rate, and durability lag.
Concrete example#
Event ingestion during a launch
The API validates event shape and idempotency, partitions by stable tenant-plus-bucket identity, appends durable records, and acknowledges only the agreed durability level. Aggregations run from the log asynchronously and expose freshness.
Architecture consequence: Separate durable acceptance from derived views so a slow aggregate does not throttle raw event capture.
Trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Synchronous partitioned writes | The response requires a committed authoritative result. | Key skew, cross-partition transactions, and replication bound throughput. |
| Queued writes | The caller can accept durable admission before completion. | Backlog, duplicates, cancellation, and result delivery become product states. |
| Batching | Many compatible operations can wait for a short window. | Latency rises and partial batch failure needs item-level truth. |
Failure diagnosis#
- Failure
- Most events share a date-only partition key during the daily peak.
- Impact
- One partition throttles while the fleet appears underutilized.
- Detection
- Per-key or per-partition write latency and throttling diverge from the fleet average.
- Mitigation
- Add a deterministic shard suffix, bound per-tenant admission, and fan in results when reading the bucket.
- Trade-off
- Write distribution makes range reads and rebalancing more expensive.
Design checkpoint#
Work the scenario before revealing the checklist
- Name the exact point that serializes the current write path.
- Propose a partition key and list the operations that would cross partitions.
- Define accepted, committed, processed, and failed states for the client.
- Set a backlog-age threshold and the overload action when it is crossed.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What does the acknowledgment guarantee?
- Can a retry duplicate a side effect?
- How does one hot tenant affect others?
- Which work is safe to defer or batch?
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.