A payments platform wants progressive delivery. What must the rollout observe, and which changes cannot be rolled out progressively at all?

What the rollout must observe

Not average latency, which hides everything. The signals that matter:

• Error rate by endpoint, not aggregate — a failure concentrated in one operation is invisible in the total.
• Latency percentiles, since the mean moves last.
• Business metrics: payment success rate, authorisation rate, settlement completion. These catch failures that produce no errors — a valid response with an empty result, a step silently skipped.
• Segmented by merchant tier, payment method, region and client version, because a canary healthy on aggregate while failing one segment is the specific failure this analysis exists to catch — and the affected segment is often the newest or the largest.

The halt conditions

Automated, with thresholds set before the rollout, because a human watching a dashboard will not react in time and will rationalise a degradation that started slowly.

And the rollback must be exercised, not documented — one that has never been run under load will fail when it is needed.

What cannot be rolled out progressively

• Changes to shared state semantics. If the new version writes a field the old version misinterprets, both versions running simultaneously is a correctness problem rather than a rollout risk.
• Changes to a calculation whose consistency across customers matters, such as a fee or interest computation — two customers receiving different treatment for the same transaction during the rollout window is a fairness and possibly a regulatory issue.
• Migrations that are not backwards compatible, which must go through expand-and-contract instead.

Identifying which changes fall into this category is a design activity, and treating every change as progressively deliverable is as wrong as treating none as such.

The financial-specific requirement

Draining. An instance being replaced must complete its in-flight operations, and for a payment the in-flight window is the external call whose outcome is unknown — terminating mid-call leaves an authorisation in an indeterminate state.

So draining must account for the operation's duration, not the request's — either waiting long enough or having a durable record from which the operation resumes elsewhere. The second is strictly better.