Dynamodb easy
When would an architect choose to implement DAX (DynamoDB Accelerator) in front of an existing DynamoDB table?
- A To reduce the physical storage cost of the table by 90%.
- B To provide millisecond-to-microsecond read latency for extremely hot keys and frequent repeated queries.
- C To enable cross-region replication for a table that was created without it.
- D To allow SQL-style JOINs between two separate DynamoDB tables.
Answer: B. To provide millisecond-to-microsecond read latency for extremely hot keys and frequent repeated queries.
DAX is a write-through, in-memory cache. It is API-compatible with DynamoDB, meaning your app can switch to DAX with minimal code changes. It is ideal for 'Read-Heavy' workloads where sub-millisecond response times are a critical requirement.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- DynamoDB has a strict 400KB limit on the size of a single item. What is the recommended design pattern if you need to store larger documents (e.g., 5MB PDFs)?
- What is the primary role of the 'Partition Key' in ensuring DynamoDB's infinite horizontal scalability?
- Why is the `Query` operation generally preferred over `Scan` for production workloads in DynamoDB?
- DynamoDB is a 'fully managed' serverless database. What is a primary operational benefit of this model for an engineering team?
- In 'Provisioned Capacity' mode, how is the performance budget of a DynamoDB table defined?
- DynamoDB supports two types of Primary Keys. What is the fundamental difference between a 'Simple' and a 'Composite' primary key?