Dynamodb hard
An item's TTL timestamp has passed, yet a `Scan` operation still returns the item 12 hours later. Is this expected behavior?
- A No, it indicates a bug in the DynamoDB internal scavenger service.
- B Yes: TTL is a 'Best Effort' background process. AWS guarantees that the item is 'eligible' for deletion after the timestamp passes, but the actual removal can take up to 48 hours depending on table traffic and system load.
- C No, TTL items are deleted from the disk within 5 minutes of expiration.
- D It means the TTL attribute was formatted as a ISO-8601 string instead of an Epoch timestamp.
Answer: B. Yes: TTL is a 'Best Effort' background process. AWS guarantees that the item is 'eligible' for deletion after the timestamp passes, but the actual removal can take up to 48 hours depending on table traffic and system load.
TTL is free precisely because it is low-priority. It uses 'extra' background cycles to clean up. Because of this 48-hour window, applications MUST use a `FilterExpression` (e.g., `WHERE expiration > now`) if they want to ensure users never see 'expired' data before the scavenger removes it physically.
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?
- When would an architect choose to implement DAX (DynamoDB Accelerator) in front of an existing DynamoDB table?