AWSAWS Certified Generative AI Developer - Professional2026-104.1 Implement cost optimization and resource efficiency strategies
Bind cached answers to complete request identity
Completed by the knowledge check
Learning objective
Build exact-response cache keys, request hashes, result fingerprints, and invalidation rules.
Core idea
An exact-response cache promises that a stored answer remains valid for the same effective request. Its key must represent every input that can change the permitted answer, not merely the words in the question. A request hash identifies those inputs compactly. A result fingerprint identifies the produced artifact. Invalidation ends permission to reuse that artifact when its dependencies change.
For a senior engineer implementing this promise, the hardest work happens before choosing the storage service. Define request equality, decide which changes create a different identity, and separate logical expiration from physical deletion. AWS supplies storage operations and retention mechanisms; your application owns the semantic contract connecting them.
How it works
Define the effective request
Create a versioned application cache contract from the request you actually execute. With Bedrock Converse, relevant request fields include modelId, system, messages, inferenceConfig, toolConfig, guardrailConfig, and additionalModelRequestFields. Include the fields used by your workload rather than treating this list as exhaustive. A prompt-management or routing decision must resolve to a known configuration revision before lookup.
Add application dependencies that the model request alone might not expose. These include the prompt-template revision, output-schema revision, language, retrieved document identities and revisions, tool-result snapshots, and authorization scope. If those inputs cannot be established before lookup, either perform the required context assembly first or bypass caching. A corpus revision is useful only when it reliably identifies the evidence contract relevant to that answer.
Exclude values that do not affect the answer, such as an observability correlation ID, from the reusable identity. Otherwise, every call becomes unique. Do not exclude a field merely because it reduces hit rate: an account, product release, or conversation turn can be a correctness dependency. Access-scope design belongs to 4.1.9.
Canonicalize before hashing
Define one canonical serialization for the contract. Object-property order, numeric representation, optional defaults, and Unicode handling must be deliberate so that equivalent requests yield the same bytes. Preserve message and content-block order because it carries meaning. Do not sort retrieved passages or tool messages unless your contract explicitly makes their order irrelevant.
Normalize only proven equivalences. Collapsing whitespace in quoted code, dropping punctuation from identifiers, or lowercasing case-sensitive product names can merge requests that require different answers. Hashing an unsafe normalization faithfully preserves the unsafe equivalence; it cannot repair it.
An application can calculate a cryptographic request hash, such as SHA-256, over the canonical bytes and place it beneath a versioned, authorized namespace. The algorithm choice is an application design, not a DynamoDB feature. Store the contract version and dependency metadata with the answer so that you can explain a hit and detect incompatible records.
A hash is also not an authorization decision or encryption. A compact key does not justify exposing cached answers to another principal. Avoid raw sensitive prompts in operational key names, and keep any diagnostic request material under the same access and retention controls as the answer.
Separate request and result identity
The request hash answers, “Which effective input produced this candidate?” The result fingerprint answers, “Which output artifact is this?” Compute the result fingerprint over the accepted response representation: answer bytes or a canonical structured result, plus citations and output-schema version when they are part of the delivered artifact.
Do not replace the request key with the result fingerprint. Two different questions can generate the same short answer, yet have different evidence or permissions. Conversely, the same request can generate different acceptable answers. A result fingerprint lets you compare stored artifacts, detect unintended mutations, and associate evaluation evidence with one artifact; it does not prove that artifact is factually correct.
Only publish complete, validated responses. A timeout, partial stream, or failed output-schema check must not become an ordinary success entry. If you deliberately cache another outcome, give it a separate status and validity policy so that an error record cannot masquerade as an accepted answer.
Enforce validity at lookup
DynamoDB supports a concrete implementation: use the authorization namespace as a partition key, the request hash as a sort key, and GetItem with both key values. Store the accepted artifact, fingerprint, dependency revisions, creation time, and application expiration time with PutItem. DynamoDB items are limited to 400 KB, so eligibility must also account for answer and metadata size.
PutItem replaces an existing item with the same key by default. A conditional write can prevent an unintended overwrite when competing workers publish results; DynamoDB supports condition expressions for item writes. Choose the race policy explicitly, including whether the first valid answer or an approved replacement should win. A database condition does not itself establish that the generation used fresh dependencies.
Enable DynamoDB time to live (TTL) on a Number attribute holding Unix epoch seconds for cleanup. Expired items are typically removed within a few days, so reject an expired record in application code even if GetItem still returns it. TTL deletion is not the reuse deadline.
For source, prompt, model-configuration, schema, or authorization changes, advance the relevant revision in the identity so new requests cannot select old records. Use DeleteItem when explicit removal is required. For strict revocation, consult the authoritative current revision before returning a hit, and reject a candidate that no longer matches it. GetItem is eventually consistent by default; ConsistentRead: true supplies a strongly consistent item read when required. It does not make separate source systems atomic with the cache.
Key distinctions and trade-offs
A short key is efficient, but omitted dependencies produce false hits. A complete key may lower hit rate because it correctly distinguishes requests. Treat that reduction as evidence of meaningful variation rather than automatically weakening identity.
Version-based invalidation makes old records unreachable to new requests without requiring synchronous bulk deletion. It still needs expiration or explicit deletion for storage cleanup, and deletion obligations remain separate; see 3.2.10. TTL handles time-based cleanup, while revision checks handle correctness changes that can occur before a TTL ends.
Exact matching also differs from idempotency. Returning a cached explanation can be acceptable; returning a previous explanation of a tool action does not establish whether a requested action executed. Keep execution tracking separate from response reuse; see 2.1.11.
Architecture / decision scenario
A warranty assistant answers the same question for a product and jurisdiction. The application constructs a canonical contract containing the product release, jurisdiction, authorized scope, ordered question context, prompt revision, selected model configuration, and warranty-document revision.
It hashes that contract and performs a DynamoDB GetItem. A returned record must have the matching contract version and unexpired application timestamp. The stored result fingerprint identifies the accepted answer and citations for later review, while a conditional PutItem governs competing cache fills.
When the warranty policy changes, the authoritative document revision advances. New lookups use a new hash, and an in-flight result carrying the previous revision fails the publication or reuse check. DynamoDB TTL cleans up obsolete records later. When a reviewer finds a defective answer, the team uses DeleteItem for that record and corrects the validation rule before allowing it to be repopulated.
Common exam traps
- Hashing only the user question while omitting evidence or configuration revisions.
- Assuming hashing makes an incomplete key complete, private, or authorized.
- Sorting meaningful message order to increase exact-match hits.
- Confusing a result fingerprint with a request identity or correctness proof.
- Returning an expired DynamoDB item until TTL physically deletes it.
- Assuming a strongly consistent cache read guarantees freshness in every dependency.
What to remember
Canonicalize the effective request, hash it beneath the permitted scope, and store the accepted artifact with a distinct result fingerprint. Advance dependency revisions when reuse rules change. Enforce expiration and revocation before returning a hit; use DynamoDB TTL for cleanup rather than as the correctness gate.
Knowledge check
A warranty assistant’s exact-response cache hashes the question text and modelId. After the warranty policy document is revised, users still receive answers based on the old policy until the records expire. Which change prevents these hits?
ConsistentRead set to trueTo raise the hit rate, a canonicalizer sorts the conversation’s messages alphabetically before hashing. Which rule should canonicalization follow instead?
Two different questions produced the same short accepted answer. A developer proposes keying the cache on the result fingerprint, so that both questions share one record. Why is this wrong?
GetItem returns a cache record whose application expiration time has passed. DynamoDB TTL is enabled but has not yet deleted the item. What should the lookup do?