Partition & Sort Keys Interview Questions

It hashes to a storage partition that owns that key’s items and their throughput budget. Uneven keys pile traffic onto few partitions and throttle while the rest of the table looks idle. High cardinality and even access are therefore part of the data model, not only capacity settings.

Equality, <, <=, >, >=, between, and begins_with—always together with a full partition key. You cannot Query “all sort keys matching a prefix” across the table without a GSI. FilterExpression after the Query is not a substitute for a sort-key condition; it still reads matching PK items.

The composite primary key is the item’s identity. A second Put with the same PK+SK overwrites (or fails a condition), it does not append a row. If you need history, encode uniqueness in the sort key (timestamp, UUID) instead of reusing the same pair.

A convention such as ADDR#home or ORDER#2026-09-18#<id> groups related children so one Query retrieves a type or a date prefix. Depth is limited by the string you store, not by SQL-style foreign keys. Poorly padded dates or mixed casings break the intended range.

DynamoDB locates items by hashing that key; without it the request would be a Scan. APIs that omit PK are a modeling failure, not a missing WHERE clause. If callers only know an email or SKU, that attribute belongs on a GSI as the index partition key.

Use it for true 1:1 lookup items—session tokens, feature flags, a user profile with no child collection on that table. Adding an unused sort key complicates every Get. As soon as you need 1:N under the same identity, switch to a composite key rather than stuffing arrays into one item.

Keys such as status=OPEN or date=today concentrate today’s traffic on one partition. Adaptive capacity helps brief spikes, not a permanent celebrity key. Combine a high-cardinality identifier, or shard the time bucket, if that access pattern is required.

Concatenate typed segments (ENTITY#id#TS) so begins_with can peel the hierarchy. Document the exact separator and zero-padding so range queries stay ordered. Overloaded sort keys are powerful; undocumented ones become unqueryable archaeology.

CloudWatch throttling with healthy table-level consumed capacity, plus Contributor Insights on most-accessed keys, usually means one PK value. Client retries then amplify the hotspot. Fix the key or cache that item; raising provisioned WCUs on the whole table rarely fixes skew.

It can shift extra throughput toward a partition that is briefly hotter than its neighbors. It cannot invent more than the table’s limits or repair a key that is hot all day, every day. Permanent skew still needs sharding, caching, or a different PK.

Use a sort key that orders by time (ISO-8601 or zero-padded epoch) and Query ScanIndexForward=false with a Limit. Do not Scan the table and sort in the app. If “newest” must be global across all users, that is a different key or a GSI, not a local collection trick.

All items that share a partition key form a collection. LSIs are scoped to that collection, and some transactional patterns assume colocated items. A collection that grows without bound also grows Query cost for anything that reads a wide SK range.

String comparison is lexicographic: "9" sorts after "10" unless you pad (0009, 0010) or use a fixed-width epoch. Mixed types coerced to strings will not match human numeric order. Interviews often catch this on “list IDs 1..11” style keys.

Shard when the entity must exist but is too hot (popular product, viral user). Change the pattern when you were hashing on the wrong attribute. Sharding adds fan-out reads; do not shard a key you could have Query’d on a GSI with even cardinality instead.

Include a high-cardinality dimension (deviceId, customerId) as PK and time as SK, or shard the time bucket (day#shard). A PK of YYYY-MM-DD alone collapses midnight traffic onto one partition. Downsampling to rollup items is the usual way to keep Query windows bounded.

PK=userId with SK=PROFILE for the profile item and SK=ORDER#<timestamp>#<orderId> for orders. GetItem or Query equal on PROFILE; Query begins_with ORDER# plus a timestamp range for history. A GSI is only needed if you must also look up by orderId alone.

Dual-write old and new keys, backfill, switch readers with a flag, then stop old writes. In-place rewrite of PK is not supported; you copy items. Keep idempotent keys so retries do not create twins during the overlap window.

New writes always hit the tail of the same partition, which can create a hot key even when cardinality looks high. Random suffixes, swapping time into the PK, or caching the tail mitigate it. This shows up in append-only feeds and high-rate event logs.

PK includes tenantId so IAM LeadingKeys and Query paths cannot wander. A GSI on userId (or email) lets support find the tenant+user without scanning. Never use a global PK=userId if tenants can collide or if isolation must be cryptographic in IAM.

Generate realistic key cardinality in a load test, not a tight loop on one PK. Measure throttles per key, p99, and consumed capacity. A test that reuses USER#1 proves nothing about partition spread and often ships a hotspot into production.