A company is building an application for stock trading. The application needs sub-millisecond latency for processing trade requests. The company uses Amazon DynamoDB to store all the trading data…

Question

Options

• AAdd local secondary indexes (LSIs) for the trading data.
• BStore the trading data in Amazon S3, and use S3 Transfer Acceleration.
• CAdd retries with exponential backoff for DynamoDB queries.
• DUse DynamoDB Accelerator (DAX) to cache the trading data.

• A
  6% (1)
• C
  12% (2)
• D
  82% (14)

Explanation

DAX (DynamoDB Accelerator) is an in-memory caching layer purpose-built for DynamoDB that delivers microsecond read latency - exactly what sub-millisecond stock trading requires - and requires minimal code changes (just point your SDK client at the DAX cluster instead of DynamoDB directly).

Why the distractors fail:

• A (LSIs): Local Secondary Indexes improve query flexibility and can help with specific access patterns, but they don't cache data in memory or fundamentally reduce retrieval latency to sub-millisecond levels.
• B (S3 + Transfer Acceleration): S3 is object storage optimized for large files, not low-latency transactional data access; Transfer Acceleration reduces upload/download time over long distances but is completely wrong for this use case.
• C (Exponential backoff): Retries with backoff are a resilience pattern for handling throttling errors - they actually increase total latency on failure and do nothing to improve normal retrieval speed.

Memory tip: Think DAX = DynamoDB's turbo button - it sits in front of DynamoDB like a cache, turns milliseconds into microseconds, and is a drop-in solution (least effort). Whenever an exam question pairs DynamoDB with "sub-millisecond," "caching," or "reduce read latency," DAX is almost always the answer.

No community discussion yet for this question.