# Reliability Wants the Payload. Privacy Wants It Deleted.

Replay needs payload retention. Data minimization pushes the other way. Here’s how to separate delivery history, payload retention and access without giving up reliability.

Author: Sverre Senneset — CEO, Queuey
Published: 2026-10-06

One of the useful things about a delivery layer is that you can replay events when something goes wrong. If a destination has been misconfigured, an endpoint has been down for a few hours or an event needs to be inspected and sent again, it is extremely useful to still have the original payload available.

The obvious consequence is that if you want to replay an event later, you need to keep enough data to recreate it. Replay is therefore not only a reliability feature. It is also a retention decision.

From a reliability perspective, keeping payloads for some time gives you more options when something fails and makes recovery easier. From a privacy perspective, the direction is usually the opposite: keep less data, limit who can see it and delete it when it is no longer needed.

The real decision is how much of the event you need to keep, and how long you need it.

## Replay means retention

If an event is successfully delivered today and the payload is deleted immediately afterwards, you can still keep the delivery history. You can know when it arrived, where it was sent, how many attempts were made, what the destination returned and how long delivery took. For many operational questions, that is enough.

What you can no longer do is replay the original event next week.

If you want a seven-day replay window, you need to retain enough of the event for seven days. If you want 30 days, the same applies for 30 days. That is simply part of what replay requires.

It is therefore useful to separate delivery history from the payload itself. The operational history may be worth keeping for months, while the original event data may only be needed for a much shorter period. A successfully delivered event and an event that is still waiting for recovery do not necessarily need the same retention policy either.

An event waiting for a destination that is temporarily unavailable still needs its payload if it is going to be delivered later. A rejected event may need to stay around long enough for someone to inspect and correct it. Once an event has been delivered successfully, the reason for keeping the full payload is often weaker.

## Keeping a payload does not mean everyone needs to see it

Retention and access are two different questions. A payload may need to remain available for replay without being part of normal operational access.

In many cases, metadata tells you most of what you need to know. If you can see that an event failed with a `422`, which destination it was sent to, when it happened and how many attempts were made, you may already have enough information to investigate the problem. The actual customer data may add very little.

That means payload access can be restricted even if the payload itself is retained. You can keep it available for recovery while still controlling who can inspect it and recording when someone does.

This matters most when payloads contain customer data, financial information or other sensitive business data. Reliability may require keeping the event for a period of time. It does not require making the contents broadly visible.

## The source system matters too

The delivery layer is not always the only place where the event exists.

If the source system keeps a durable event history and can safely republish old events, the delivery layer may not need to retain payloads for very long. If the source sends an event once and then forgets about it, the delivery layer may be the only place from which that event can ever be recovered.

That changes how valuable long retention actually is. If the event can be recreated elsewhere, keeping another full copy for months may add little. If it cannot, deleting it also removes the option to recover it later.

## How we handle it in Queuey

In Queuey, delivery history and payload retention are separate. You can keep the operational history without keeping the payload indefinitely.

Delete the payload after successful delivery and you give up historical replay. Retain it, and replay remains available for that retention period.

**A replay window is also a retention window.**

Source: https://queuey.ai/articles/reliability-wants-the-payload-privacy-wants-it-deleted/