A payments platform's fraud service is degraded during a peak commerce event. Should the payment path wait, skip the check, use cached risk scores, fall back to simpler rules, or fail? What should determine the answer?

What determines the answer

Not availability, but the expected cost of each error. Skipping the fraud check means accepting some fraudulent transactions; failing the payment means rejecting many legitimate ones. Those have different magnitudes and different distributions, and the decision belongs to risk and product, decided in advance, rather than to an engineer at 9pm.

The answer that usually holds

A tiered fallback, not a binary.

• Primary: the full model-based check, with a hard deadline.
• On deadline breach: cached risk scores for known entities — this device, this merchant, this card — which covers a large fraction of traffic since most transactions are from returning users.
• On cache miss: a simple deterministic rule set that runs locally, in microseconds, with no external dependency. Amount thresholds, velocity limits, obvious-signal blocks.
• Only fail closed above a value threshold, where the expected loss from a fraudulent transaction exceeds the cost of rejecting a legitimate one.

The crucial design property is that the fallback is graduated by transaction value, so a small payment proceeds on weak signals and a large one does not. A single policy for all values is either too permissive at the top or too restrictive at the bottom.

What must be true for this to work

• The simple rules must run locally with no network dependency, or the fallback shares the failure it is meant to survive.
• The degraded mode must be observable, so the business knows how much traffic passed on weak signals and can act on it.
• Transactions decided in degraded mode must be marked, so they can be re-evaluated asynchronously and reversed if warranted — which converts an irreversible decision into a deferred one.
• The degraded path must be exercised regularly, because a fallback that has never run in production will not work when it is needed.

The framing to take away

Graceful degradation is a product decision expressed in code, and the engineering question is only how to implement the decision. A team that has not had the conversation with risk and product will make the choice implicitly — usually by whatever the timeout handler happens to do — and that default is almost always wrong in one direction or the other.