Best Practices Interview Questions

DynamoDB does not join across tables efficiently, so you model the queries you must serve first. List read/write paths, then choose partition and sort keys that answer those paths with Query rather than Scan. A 3NF schema imported from SQL usually produces hot partitions, extra round-trips, or expensive scans.

Pick an attribute with high cardinality that spreads traffic evenly, such as userId or orderId, not a low-cardinality status flag. Watch CloudWatch for throttling concentrated on one partition key value. If a popular entity still dominates traffic, add a sharding suffix or cache that item.

Use a sort key when many items share a partition and you need range queries, newest-first lists, or 1:N collections such as ORDERS#<id> under a customer partition. Begins_with and between on the sort key keep related items colocated without a Scan. Skip a sort key only for true single-item lookups.

Query reads only items that match a partition key (and optional sort-key condition), so cost and latency stay proportional to the result set. Scan reads the whole table or index and burns capacity even when you filter afterward. Use Scan for rare admin jobs, not user-facing request paths.

Keep items small: store large blobs in S3 and persist the object key in DynamoDB, or split wide documents into multiple items under the same partition. Oversized items increase read cost, slow replication, and fail writes. Compress only when you still stay well under the limit and can decode consistently.

A sparse GSI only projects items that actually have the index’s key attributes, so most rows never appear. Use it for rare states such as “pending review” without duplicating the entire table. That keeps the index small, cheaper to write, and fast to Query.

On-demand fits spiky or unknown traffic because you pay per request and skip capacity planning. Provisioned (with auto scaling) is usually cheaper for steady, predictable load. Switch only after measuring request rates; mixing modes without a traffic profile often wastes money or still throttles.

Append a shard suffix (userId#0 … userId#N) on writes and fan out reads across shards, or cache the hot item. Adaptive capacity helps short bursts but will not fix a permanently skewed key. Document shard count and aggregation so new features do not write to a single physical partition again.

Use TransactWriteItems when multiple items must commit or fail together, such as inventory decrement plus order create. Transactions cost extra write units and cap at 100 items, so do not wrap every request. For idempotent retries of one item, a condition expression is cheaper and sufficient.

TTL deletes expired items in the background so session, cache, and event tables do not grow forever. Deletion is eventually consistent and not real-time, so do not treat TTL as a security purge SLA. Combine TTL with Streams if downstream systems must react to expiry.

Retry with exponential backoff and jitter on ProvisionedThroughputExceededException or HTTP 429. Make writes idempotent with client tokens or condition checks so retries do not double-apply money or inventory changes. Unbounded immediate retries amplify hot partitions and make throttling worse.

Store a version attribute and require it to match on UpdateItem so concurrent writers cannot silently overwrite each other. On condition failure, re-read, merge, and retry. This is the standard DynamoDB alternative to relational row locks and pairs well with retries that are already required for throttling.

DAX helps read-heavy, key-value access patterns that tolerate microsecond cache hits and can accept eventually consistent cached data. It does not speed Queries/Scans the same way and is a poor fix for a bad data model. Strongly consistent reads bypass DAX, so design which paths may be stale.

Single-table design can colocate related access patterns and reduce round-trips when the team can own generic keys and GSIs. Multiple tables are clearer when bounded contexts, IAM, or backup cadences differ. Interviewers want the trade-off: operational simplicity versus access-pattern efficiency—not a dogma.

Keep items small, prefer Query over Scan, use BatchGet/BatchWrite within limits, and cache hot keys. Provisioned tables need auto scaling plus enough headroom; on-demand still needs even partition spread. Isolate bursty workloads (analytics exports) from user-facing tables so one job cannot dominate p99.

Enable point-in-time recovery for accidental deletes and bad deploys, plus on-demand backups before schema-risking migrations. Practice restoring into a new table and cutting traffic over; never assume a backup works until you have timed an RTO drill. Document RPO/RTO separately from application-level undo.

Have the write path persist the source of truth, then process INSERT/MODIFY/REMOVE records asynchronously with Lambda or Kinesis adapters. Use the sequence number and idempotent consumers so retries do not duplicate side effects. Avoid synchronous fan-out inside the original API call, which raises latency and failure blast radius.

Grant least-privilege IAM actions scoped to table and index ARNs, require encryption at rest (AWS owned, KMS, or customer managed), and use TLS in transit. Prefer VPC endpoints over public internet from private subnets. Audit with CloudTrail and block wildcard resource policies in production accounts.

Global Tables replicate across regions for low-latency local reads and regional failover. Replicas are eventually consistent across regions, so last-writer-wins can drop concurrent updates unless you add application-level conflict handling. Use them when locality or DR matters more than a single-region strong-consistency story.

Sustained ThrottledRequests, UserErrors, high ConsumedWriteCapacity on few keys, and SystemErrors during bursts all point at hot partitions or oversized items. Contributor Insights shows the hottest keys and most throttled operations. Fix the key design or cache before blindly raising provisioned capacity.