Android and iOS

Exercising a RASP service outage

Latency, availability, incident response and protection policies.

Production operations1 min readEditorial methods

Test dependency failures before they happen. Exercises show how user flows and server policies behave under uncertainty.

Evaluation approach

Treat timeouts, invalid responses and network absence as separate scenarios. Check messages, transaction state and operational alerts together.

Application example

Verify that an unreachable verification service does not duplicate a payment and that pending work follows the intended safe policy.

Limits and considerations

A complete shutdown does not reproduce every slowdown or partial failure.

Test recovery too

Making verification unreachable is only the beginning. Examine waiting, errors and retries, then determine how old events and operations are handled when service returns.

Retries must not amplify load or duplicate transactions. The user-visible state should agree with the server's actual outcome. Use the exercise to refine default failure policy and support flows.

Checks and decisions

  • Test partial failures
  • Limit retries
  • Measure recovery

Use findings to improve policies, support procedures and alerts.

Sources

The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.