Idempotency key vs Content cache key

difference

Idempotency key

don’t do the side-effect twice

• scope: a specific operation
• storage: usually a UNIQUE constraint or a short-lived “seen” table
• stable even if implementation details change

Content cache key

• don’t recompute if inputs didn’t change
• scope: a specific computation, like summarizing things
• derived from inputs (e.g., hash(content + prompt_version + model))
• changes whenever inputs change

can a content cache key also be an idempotency key?

unlikely
only if the operation’s effect is entirely determined by those inputs and the scope matches the business rule

can an idempotency key double as a cache key?

also unlikely
idempotency key prevents duplicate effects, not redundant computation.

takeaway

Algorithm drift:

• change your summarization prompt/model → cache key changes (good)
• but idempotency keys should not change because you refactored code