# Should a background job store a snapshot of its input or fetch current data when it runs? > Use snapshots for reproducibility, references for freshness, and version-bound references when you need both auditability and smaller queue payloads. Canonical URL: https://www.devobs.io/articles/qa-enqueue-reference-snapshot/ By: Amara Okafor Published: 2023-04-18T00:42:04.966Z Updated: 2026-09-06T08:31:04.426Z Section: Architecture Use a snapshot when the job must reproduce the user’s original intent exactly; use a reference when the job should act on the latest state at execution time. If you need both auditability and smaller messages, queue a reference plus an explicit version or content hash. That contract matters more than the queue technology: it decides how your system behaves when records change, disappear, or grow too large for the queue’s message limits such as Amazon SQS’s 1 MiB maximum message size in [Amazon SQS message quotas](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html). ## What decision are you really making? You are choosing the job’s data contract, not just its payload format. A snapshot says, “process this exact input later.” A reference says, “look up whatever the current record is later.” A version-bound reference says, “fetch record X, but only version 17.” That choice should follow the business meaning of the job. If a workflow must be replayable and understandable later, preserving the original state usually wins. Temporal’s workflow model is a useful mental frame here: workflow execution relies on persisted state and event history so work can resume from “the latest state” and replay against an existing history, as described in [Temporal Workflow Execution](https://docs.temporal.io/workflow-execution). Even outside Temporal, background work is easier to reason about when the important inputs are stable. ## When should you store a snapshot? Store a snapshot for irreversible or externally visible outcomes: invoice generation, tax calculation, order confirmation, outbound emails, and compliance exports. In those cases, “what the user meant when they clicked” matters more than “what the database says now.” Worked example: - Invoice generation: snapshot line items, prices, tax jurisdiction inputs, and billing address at enqueue time. - Search index refresh: queue only the document ID and fetch the current record when the worker runs. If a customer changes their address after checkout, regenerating an old invoice from current customer data is usually wrong. By contrast, a search reindex job should usually reflect the newest title, tags, and visibility flags. ## When should you fetch current data instead? Fetch current data when the job’s purpose is synchronization, enrichment, recalculation, or cache/index maintenance. These jobs exist to converge on the latest truth. Storing a full snapshot just increases payload size and stale-data risk. This approach also helps with queue limits. On SQS, a message can have at most 10 attributes and a maximum size of 1,048,576 bytes, according to [Amazon SQS message quotas](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/quotas-messages.html). Large snapshots quickly become fragile, especially once you add retries, batching, and [schema evolution](https://www.devobs.io/articles/schema-evolution-for-event-streams/). ## How do mutable records and deletion change the design? If records can change or be deleted before execution, plain references are not enough for intent-preserving jobs. Use one of these patterns: - Snapshot in the message for small, critical inputs. - Snapshot in blob/object storage, with the queue carrying a pointer. - Reference plus version number, row timestamp, or content hash. - Reference plus a tombstone policy: if missing at execution time, fail, skip, or reconstruct from audit data. A practical checklist: 1. Must the result match enqueue-time intent exactly? Use a snapshot. 2. Must the result reflect latest state? Use a reference. 3. Need both traceability and smaller messages? Use a version-bound reference. 4. Can the record be deleted before execution? Define missing-record behavior explicitly. 5. Could the payload approach queue limits? Move snapshots out of the queue. ## Follow-up: what about retries? Retries favor snapshots for intent-preserving jobs. A retry days later should not silently produce a different invoice because customer data changed. ## Follow-up: what if only some fields matter? Snapshot only the fields that define the decision. For an email job, that might be template ID, recipient address, and rendered variables—not the entire user row. Next step: pick one job in your system and write its enqueue contract in one sentence: exact-input, latest-state, or version-bound. Then make the worker reject any payload that does not match that contract. Reviewed: 2026-09-05. ## Source references - -