Traffic Mirroring
Traffic mirroring lets Eve serve the client response from the primary endpoint while asynchronously mirroring eligible native gateway traffic to secondary endpoints.
Mirror mode is a capability of Eve's native gateway runtime. It is used when operators need evidence from a secondary backend without changing the response path observed by the client.
Use Cases
- Secondary endpoint comparison and validation.
- High-availability validation with additional Redis or Valkey targets.
- Shadow traffic for compatibility testing.
- Non-blocking request analysis against a secondary backend.
- Backend profile readiness and compatibility checks before a production change.
Configuration
{
"settings": {
"mirror": {
"enabled": true,
"mode": "mirror",
"mirror_endpoint_uuids": ["7a2e4f1b-0000-0000-0000-000000000000"],
"mirror_reads": true,
"mirror_writes": true,
"sample_ratio": 1.0,
"max_in_flight_per_mirror": 128
}
}
}Configuration Fields
| Field | Behavior |
|---|---|
enabled | Turns mirroring on for the listener configuration. |
mode | Selects mirror behavior for eligible traffic. |
mirror_endpoint_uuids | Lists secondary endpoints that receive mirrored traffic. |
mirror_reads | Allows read traffic to be mirrored. |
mirror_writes | Allows write traffic to be mirrored when the secondary is prepared for it. |
sample_ratio | Limits the percentage of eligible traffic mirrored. |
max_in_flight_per_mirror | Bounds queued and active mirror work for each secondary endpoint. |
Mirror endpoints should represent the same backend family as the primary so processors can compare compatible commands, queries, payloads, or responses. Keep the secondary isolated or otherwise prepared for the mirrored traffic it receives.
Rules
- Mirror endpoints must be direct endpoints in the same organization.
- Mirror endpoints must use the same endpoint kind as the primary.
- Mirror mode is best effort and does not change the primary client response.
- Mirrored work must stay bounded by
sample_ratioandmax_in_flight_per_mirror. - Mirror results should be recorded as comparison and validation evidence, not used to mutate the primary response.
Evidence And Failure Behavior
Mirror telemetry records queued, completed, skipped, and failed mirror attempts with endpoint identifiers, latency, route, and safe status metadata. A mirror failure does not fail the primary client request unless an independent validation policy explicitly requires that behavior.
Use mirror mode with conservative sampling before increasing traffic volume. For write traffic, confirm that the secondary backend is isolated or intentionally prepared to receive shadow writes.
Operating Guidance
Start with read traffic and a small sample_ratio while validating latency, error rates, and backend capacity. Increase write mirroring only when the secondary system is safe to mutate or intentionally isolated for replay/comparison.
Mirror mode should be paired with dashboards or validation jobs that compare status, latency, result shape, and compatibility. It is not a replacement for change controls; it provides evidence that helps operators decide whether a secondary endpoint is ready for fallback or compatibility use.