Skip to content

CONCEPT Cited by 1 source

Consistency threshold per endpoint

Definition

Consistency threshold per endpoint is the parallel-run readiness criterion: each endpoint (identified by operation_id in Zalando's variant) gets its own target match-rate percentage at which it's declared "consistent enough" and ready for cutover — rather than a fleet-wide consistency bar.

Rationale

  • Marginal cost of matching increases sharply near 100%. "As usual, fixing those last few percentages has a cost higher than the value it brings" — diminishing returns hit different endpoints at different points.
  • Endpoints are independent. "Given that each endpoint is completely separated from one another, each endpoint had its own target percentage to consider it consistent (enough)."
  • Per-endpoint risk profile differs. A read-only endpoint returning catalog data has different consequences for mismatches than a POST endpoint that triggers a refund — their thresholds should differ.
  • Unblocks cutover for ready endpoints while others keep iterating. Gating the whole migration on the slowest endpoint wastes time and keeps the request-doubling cost running longer than needed.

Shape

  • Metrics are keyed by operation_id (or equivalent endpoint identifier).
  • Each endpoint has a documented target percentage — e.g., "95% match for GET /returns/:id, 99.9% match for POST /returns".
  • The triad of Matched / Unmatched / Failed counters is tracked separately per endpoint.
  • Once the rolling match rate exceeds the target for a sustained window, the endpoint is cut over (patterns/gradual-per-endpoint-cutover).

What's NOT the threshold

  • Not byte-equality across all headers. Headers like Date, X-Request-Id, transfer-encoding are deterministically different across the two systems; they're ignored by the comparator.
  • Not 100% match. "Fixing those last few percentages has a cost higher than the value it brings" — the last 1-5% is usually comparator tuning, not real semantic divergence.
  • Not the same across endpoints. Global thresholds miss the per-endpoint risk/cost asymmetry.

Zalando framing

"Each endpoint of the monolith has its own expected consistency to be reached in order to declare the migration successful. Once that threshold has been achieved, the migration can be considered safe, and we can perform the switch from the monolith to the new Returns microservice for that endpoint." (Source: sources/2021-11-03-zalando-parallel-run-pattern-a-migration-technique-in-microservices)

Zalando does not disclose concrete target percentages.

Failure modes

  • No threshold per endpoint → cutover becomes a judgement call under pressure, often triggered by timeline rather than data.
  • Threshold too tight → endpoint never cuts over; parallel run runs forever, bleeding compute cost and maintainer attention.
  • Threshold too loose → endpoint cuts over with real semantic drift still in place, which the post-cutover system exhibits as incidents that took weeks to surface.
  • Threshold set without comparator tuning discipline — spurious Unmatched from ignored headers / PDF metadata / ordering noise produces a match rate that underestimates real equivalence.

Seen in

Last updated · 550 distilled / 1,221 read