Amazon AWS SAA-C03: DynamoDB Partition Design

DynamoDB partition design is an access-pattern problem before it is a capacity problem. A table distributes items according to the partition key, and the quality of that key determines whether read and write traffic spreads across storage partitions or concentrates on a small number of hot values. A schema can look elegant and still throttle if one tenant, device, date, or status value receives most of the traffic.

AWS currently documents that each DynamoDB partition is designed to support up to 3,000 read units per second and 1,000 write units per second, with item size affecting how quickly those units are consumed. Adaptive capacity applies to both on-demand and provisioned capacity modes, but it is not a reason to design a chronically hot key. Good key distribution gives adaptive capacity room to help when real traffic is temporarily uneven.

Partition-key engineering belongs inside AWS Architecture in Practice.

Start from access patterns

List the reads and writes the application must perform before choosing a key.

Database choice should already have established that the workload benefits from DynamoDB’s key-value/document model and known access paths.

The partition key should make the dominant access patterns efficient while distributing their request volume across enough values.

Avoid low-cardinality hot keys

Keys such as status=OPEN, region=us-east-1, or one timestamp bucket can concentrate large workloads on very few logical values.

Even a table with enormous total capacity can throttle one hot partition if a single key receives traffic above the partition’s sustainable limit.

High cardinality helps because traffic naturally spreads across more key values and physical partitions.

Use composite keys for related items

A composite primary key combines a partition key with a sort key.

This lets one partition-key value group related items while the sort key supports ordering and range queries inside that item collection.

The grouping should remain bounded; one giant tenant or account can still become hot if every request targets the same partition key.

Use write sharding when one logical key is too hot

AWS recommends write sharding when a naturally concentrated workload must distribute writes across several partition-key values.

The application can append or derive a shard suffix and write each item to one of several logical shards.

The tradeoff is read complexity because queries that need the entire logical group may have to read several shards and merge results.

Understand adaptive capacity

Adaptive capacity can increase the share of table capacity available to imbalanced partitions and can isolate frequently accessed items over time.

It protects real workloads from temporary skew, but it cannot make one physical partition exceed its documented per-partition throughput ceiling.

Serverless capacity still needs architecture because automatic capacity management does not remove hard limits or inefficient access patterns.

Design GSIs with the same discipline

Global secondary indexes have their own partition keys and can develop hot partitions independently from the base table.

A base-table design with excellent distribution can still throttle when a GSI uses a low-cardinality or highly skewed key.

Evaluate each index against the traffic pattern that will actually use it, including write amplification from base-table updates.

Choose on-demand or provisioned separately

On-demand mode simplifies throughput management for unpredictable workloads, while provisioned mode can fit predictable demand and explicit capacity planning.

The capacity mode does not change the need for an effective partition key.

Architects should compare traffic variability, cost, scaling behavior, and workload limits rather than use on-demand as a substitute for schema design.

Monitor consumed capacity by key

CloudWatch table metrics show throttling and capacity pressure, while Contributor Insights can help identify frequently accessed keys.

When throttling appears, determine whether the problem is table-level capacity, an isolated hot key, an index, or one unusually large item.

Evidence should guide whether to change capacity, shard the key, cache reads, or redesign an access pattern.

Keep partition design reversible

Primary keys cannot be casually changed on a live table, so high-volume systems need migration plans when access patterns evolve.

For SAA-C03 and SAP-C02, the durable method is access patterns → key cardinality → item-collection size → index design → traffic test → monitoring. DynamoDB scales best when the data model distributes work naturally before capacity features are asked to compensate.

Item size belongs in partition analysis because throughput units are based on bytes as well as request count. A 20 KB strongly consistent read consumes more capacity than a 4 KB read, so one high-cardinality key can still create pressure if the application repeatedly reads large items. Store large binary payloads in S3 where appropriate and keep DynamoDB items focused on the data needed for access patterns.

Time-series workloads deserve special care. A partition key based only on date or hour can concentrate all current writes on one value while historical partitions sit idle. Adding device, customer, shard, or another higher-cardinality element can spread current traffic. The exact design should follow how readers retrieve recent and historical data; writing evenly is not useful if every query becomes an expensive fan-out.

Multi-tenant tables need to model tenant skew. A key such as TENANT#123 can work for many small tenants while one very large customer becomes a hot partition. Large-tenant detection and optional tenant-specific sharding are safer than assuming every customer has similar traffic. The data model can preserve one logical tenant while physically distributing high-volume item groups.

Sequential sort keys are usually fine because sort-key ordering happens within a partition-key value. The hot-key risk appears when the partition-key value itself receives excessive traffic. This distinction prevents teams from “randomizing” sort keys unnecessarily and losing useful range-query semantics.

Global tables add regional replication but do not fix partition-key skew. Every replica table uses the same logical primary-key design, and write hot spots can be reproduced across Regions. Multi-Region architecture should therefore solve locality and disaster recovery while keeping the base partitioning model healthy in every replica.

Transactions and strongly consistent reads can increase per-request cost and should be included in load tests. A data model that passes with eventually consistent point reads may fail under the actual consistency and transactional patterns used in production. Test the API operations, item sizes, and batch sizes the application will really use.

Conditional writes can protect business invariants without central locking, but a frequently updated counter or “latest state” item can become a hot item. Consider distributed counters, event aggregation, or write-sharded designs where one item would otherwise serialize a high-volume workflow.

DynamoDB Streams can decouple downstream processing from the write path, but they inherit the partitioning order of the source. Consumers should understand that ordering is per item/partition sequence rather than one total table order. Use EventBridge, SQS, or another downstream service when broader routing or buffering semantics are required.

Local secondary indexes share the table’s partition key and therefore preserve the same item-collection boundary. Global secondary indexes can use a different partition key, which is powerful but creates a second distribution problem. Index selection should be based on an access pattern that justifies the write/storage cost and can distribute its own traffic.

Write sharding can be random or calculated. Random suffixes are simple but require fan-out reads across every shard. Calculated shards based on a stable attribute can make reads more targeted when the application knows which shard contains an item. The right choice balances write dispersion with read efficiency and operational simplicity.

Batch operations should not hide skew. BatchWriteItem and BatchGetItem can improve request efficiency, but unprocessed items can still appear when capacity is exhausted. Retry with exponential backoff and inspect whether the same keys repeatedly fail; repeated failures are often a data-distribution signal rather than a transient service issue.

Table-level monitoring should include throttled requests, consumed capacity, account/table quotas, index metrics, and latency. Contributor Insights is especially useful for identifying high-frequency keys that aggregate metrics cannot reveal. A good runbook should distinguish hot partition, exhausted table capacity, account quota, and downstream retry amplification.

Capacity testing should model bursts. On-demand mode can absorb changing demand according to documented scaling behavior, but sudden traffic patterns should still be load-tested and prewarmed or planned where AWS guidance requires it. Provisioned auto scaling also responds over time rather than predicting an instantaneous burst.

Single-table design does not mean “put everything under one partition key.” It means multiple entity types can coexist in one table using carefully designed composite keys and access patterns. Healthy single-table designs often have many partition-key values and use prefixes to express entity relationships without concentrating the entire application on one logical partition.

Migration strategy matters because primary-key changes require new items or a new table. For high-volume production systems, dual-write, stream-driven backfill, export/import, or controlled cutover may be safer than one large rewrite. Include key-design versioning early if the business expects large changes in tenant size or access patterns.

The best partition design can be explained in traffic terms: which key values exist, how many requests each receives, how large the items are, which indexes amplify writes, and what happens when one customer becomes ten times larger. That explanation is far more useful than a statement that “DynamoDB scales automatically.”