Caching and message filtering: DVA-C03 study notes and practice questions
What to know about Caching and message filtering for the DVA-C03 exam, from the Troubleshooting and Optimization domain (22% of the exam guide), then 1 free question to test it. Part of the DVA-C03 study guide.
These questions ask where to cache, what to include in the cache key, and how to send messages efficiently. The usual mistake is a cache that serves a stale or wrong answer, so check the consistency and key rules first.
Caches by data store
ElastiCache is a general cache for application data, in front of any store. The application decides what to cache and when to refresh it.
DAX is a cache for DynamoDB only. It speeds up reads that can accept eventually consistent data. Strongly consistent reads go to DynamoDB, so checkout code that needs the latest stock count should read the table directly.
CloudFront caches responses at edge locations. Its cache key decides which requests share an entry. Headers, query strings and cookies split the cache only when they are part of the key, so a page that varies by Accept-Language must include that header, or visitors get the wrong language.
API Gateway caching is a stage-level cache for REST APIs. Only the parameters you configure as cache key parameters split entries, so a query string such as category must be one. Clients can bypass the cache only when the stage allows it, so do not assume any caller can.
Messaging
SQS batching: a Lambda event source mapping reads many messages in one invocation. Larger batches and a batching window reduce invocations and cost. With partial batch responses, the function reports only the failed messages, so the rest are not retried.
SNS fan-out: one topic delivers a copy of each message to many SQS queues, Lambda functions or other endpoints, so one publisher can serve many consumers.
SNS message filtering: each subscription has a filter policy. By default, the policy matches message attributes. If the publisher puts the value only in the JSON body, set the subscription’s filter policy scope to MessageBody.
How to choose
Scenario wording
Answer
“cache DynamoDB reads, eventual is fine”
DAX
“must read the latest committed value”
Read DynamoDB directly with a strongly consistent read
“cache any database query results”
ElastiCache
“wrong language served from cache”
Add the header to the CloudFront cache key
“API cache returns the wrong category”
Add the query parameter as a cache key parameter
“fewer Lambda invocations for a queue”
SQS batching on the event source mapping
“filter on a value only in the body”
Filter policy scope set to MessageBody
Common traps
DAX for strongly consistent reads. The cache does not serve them.
Forgetting the cache key. A response that varies by a header or parameter needs that value in the key.
Expecting attribute filters to match body content.
Using SNS fan-out when one consumer needs the message; a queue is simpler.
Batching without handling partial failures, which can retry messages that already succeeded.
A payments team publishes order events to an SNS topic.
Each message sets two String message attributes, region and status, and may also have a JSON body that repeats them. A shipping queue subscribes to the topic with its filter policy scope set to MessageAttributes, and the policy is {"region": ["eu-west-2"], "status": [{"prefix": "SHIPPED_"}]}.
Which published message is delivered to the shipping queue?
Choose one answer.
AA. The region attribute is eu-west-2, and the status attribute is SHIPPED_FULL.
BB. The region attribute is eu-west-2, and the status attribute is PENDING_SHIPMENT.
CC. The region attribute is eu-west-1, and the status attribute is SHIPPED_FULL.
DD. It has no message attributes, and its body has region eu-west-2 and status SHIPPED_FULL.
B. Wrong: The status value does not start with SHIPPED_, so the prefix match fails and the message is not delivered.
C. Wrong: eu-west-1 is not in the region list, so that key fails. Every key in the policy must match, so the status match is not enough.
D. Wrong: The scope is MessageAttributes, so SNS checks attributes and ignores the body. With no attributes, neither key matches, and the message is not delivered.
Explanation
With MessageAttributes scope, each key in a filter policy must match a message attribute of that name. Within one key, any listed value or prefix may match, but every key must match. Prefix matching applies to string values, and the body is not checked in this scope.
Want more on Caching and message filtering? The 5 full-length practice sets have 6 more Caching and message filtering questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →