Question 1

What is Amazon DynamoDB and where does it fit?

Accepted Answer

Amazon DynamoDB is AWS's managed NoSQL key-value + document database with native multi-region, single-digit millisecond latency at any scale, and per-request billing. It fits when: (a) you're AWS-native and want deep IAM/Lambda/EventBridge/Kinesis integration, (b) workload is genuinely key-value or document with single-document access (no JOINs, no complex queries), (c) you need predictable single-digit ms latency at scale, (d) burst-heavy or unpredictable workloads where on-demand billing matches usage. For multi-cloud or complex query patterns, MongoDB Atlas is usually the better fit.

Question 2

Partition key design — why does it matter so much?

Accepted Answer

Partition key is the single hardest decision in DynamoDB — it's nearly irreversible without a full data rewrite via DMS / Glue. Hot partitions kill throughput (DynamoDB enforces per-partition limits even with high provisioned capacity). Best practices: (a) high-cardinality keys (user_id, request_id, sipHash of skewed populations), (b) avoid time-as-partition-key (creates hot head + dead tail), (c) composite keys for query flexibility (PK + SK pattern), (d) inverted index via GSI for alternate access patterns. We audit query patterns + write patterns before recommending the partition + sort key design.

Question 3

On-demand vs provisioned capacity — which fits?

Accepted Answer

On-demand: per-request pricing, no capacity sizing, scales instantly, ~2x per-request cost vs provisioned. Best for: unpredictable workloads, new applications, dev/test, anything spiky. Provisioned: predictable RCU/WCU per-second pricing, requires capacity planning, much cheaper at scale, supports auto-scaling. Best for: steady-state production workloads where you can size capacity. Reserved Capacity adds 50-80% discount on provisioned. We model workload shape (peak/average ratio) to recommend the right billing mode.

Question 4

Global Tables — when is multi-region worth it?

Accepted Answer

DynamoDB Global Tables provide active-active multi-region replication with last-writer-wins conflict resolution and eventual consistency across regions. Use cases: regulatory data-residency, low-latency reads for global users, rapid DR for region failure. The cost: N regions = N× write cost (writes replicate to every region) + storage + cross-region transfer. For most applications, single-region with Cross-Region Replication via DMS is cheaper. Global Tables earns its premium when active-active multi-region is a hard requirement.

Question 5

DAX caching — when does it pay off?

Accepted Answer

DynamoDB Accelerator (DAX) is a managed in-memory cache for DynamoDB — drops read latency from single-digit ms to microseconds. Use cases: (a) read-heavy workloads with cacheable hot keys (player profiles, catalog data, session state), (b) workloads where DynamoDB read cost dominates and DAX hit ratio is high enough to offset. Not useful for: write-heavy workloads, workloads with no read locality, applications already using ElastiCache. We model the workload to determine whether DAX is worth the operational + cost overhead.

Question 6

DynamoDB Streams + Lambda — what's the pattern?

Accepted Answer

DynamoDB Streams emit change events that Lambda functions process for: real-time analytics (push to Kinesis Firehose / S3 / OpenSearch), cross-region replication (alternative to Global Tables), audit logging, cache invalidation, downstream integrations. Standard pattern: DynamoDB → Streams → Lambda → target system. We design Streams + Lambda pipelines with idempotency, error handling (DLQ), and replay safety — getting these wrong creates duplicate events or data loss.

Question 7

When do you migrate from DynamoDB to MongoDB Atlas?

Accepted Answer

Common triggers: (a) multi-cloud strategy makes AWS-only lock-in problematic, (b) workload outgrew key-value access patterns and needs JOIN-equivalent (MongoDB $lookup, aggregation pipeline), (c) Atlas Search or Atlas Vector Search are central to the product, (d) team comfortable with MongoDB ergonomics over DynamoDB's constraints. Migration: AWS DMS or Glue export to S3 → MongoDB Atlas import. Application-tier rewrites are the dominant cost — see /compare/mongodb-vs-dynamodb for the deeper analysis.

Amazon DynamoDB, single-digit ms at any scale.

DynamoDB service paths

DynamoDB Consulting

MongoDB vs DynamoDB

DynamoDB vs Cosmos DB

What we build with DynamoDB

Single-digit ms at any scale

Access patterns we've transformed

Always on. Multi-region by design.

A hot-partition P1, handled in under 15 minutes.

Move to or from DynamoDB without the downtime

DynamoDB — common questions

Ready to optimise DynamoDB?

Explore Our DynamoDB Services

Compare DynamoDB