Skip to content

Guide

Traffic replay testing, explained

Traffic replay testing takes real requests captured from production and sends them to two versions of a system, the current one and the candidate, then compares what comes back. If the responses match, the change preserved behavior for the traffic you actually serve. If they differ, you see exactly where.
By the Releo team · Updated · 6 min read

How it works

  1. Capture a representative sample of real requests, with sensitive data redacted.
  2. Replay each request against the baseline and the candidate.
  3. Normalize fields that are expected to differ, such as timestamps and generated IDs.
  4. Diff the full response envelope: status code, headers, body and latency.
  5. Decide: zero unexplained divergences is evidence the change is safe; any divergence blocks the release and comes with the exact request and field.

Replay vs shadow traffic

Shadow (mirrored) traffic copies live requests to the candidate in real time and discards its responses. Replay uses recorded requests later, on demand. Replay is repeatable, which makes it suitable as a gate on a pull request; shadowing sees fresher traffic but is harder to make deterministic.

Handling non-determinism

Real responses contain values that change on every call. Comparing them naively drowns real differences in noise. Common techniques:

  • Ignore or normalize known volatile fields (timestamps, request IDs, nonces).
  • Sort arrays whose order is not part of the contract before comparing.
  • Compare the baseline against a second baseline instance to learn which fields are naturally noisy, the approach popularised by Twitter’s open-source Diffy.
  • Compare latency within a tolerance band rather than exactly.

Doing it safely

  • Redact personal and secret data before requests are stored.
  • Replay writes only against isolated environments, never against production systems of record.
  • Use idempotency keys and sandbox credentials so replayed requests cannot cause real side effects.
  • Limit retention of captured traffic to what verification needs.

Where it fits

Replay complements, rather than replaces, OpenAPI diffing and contract tests. Diffs catch structural breaks cheaply; contracts encode what consumers rely on; replay is the layer that proves behavior on real inputs. Releo makes replay the gate on every migration PR it opens.

Frequently asked questions

What is traffic replay testing?

A testing technique that re-sends recorded real-world requests to both the current and the candidate version of a service and compares the responses to find behavioral differences.

Is replaying production traffic safe?

It can be, with safeguards: redact sensitive data, replay only against isolated environments, use sandbox credentials and idempotency keys, and keep captured traffic only as long as needed.

Coming soon

Ship API changes without breaking your customers.

Releo is in private beta. Join the waitlist for early access.