Define three degradation modes for a real-time marketplace. What triggers each, what stops working, and how does the system return to normal?

What is being tested

Whether you can identify the single loop that is the product and separate it from everything that merely improves it.

The core insight

For a marketplace, the essential loop is matching. A marketplace that stops matching is down; one that matches with a slightly worse estimated arrival time is merely worse.

So the architecture must ensure the matching loop has no hard dependency on anything that only enriches it — surge calculation, precise ETAs, personalised pricing, promotions, recommendations. That is not a fallback bolted on afterwards; it is a deliberate separation designed in.

Three modes

Mode 1 — Reduced enrichment.

• Trigger: the pricing or ETA services exceed a latency threshold, or their error rate crosses a bound.
• Behaviour: matching continues using simpler heuristics — straight-line distance instead of routed ETA, base pricing instead of dynamic, no personalised ranking.
• User impact: estimates are less accurate. The product works.
• Exit: automatic, when the dependency recovers and stays healthy for a sustained window.

Mode 2 — Reduced freshness.

• Trigger: the location or demand stream lags beyond a threshold.
• Behaviour: match against the last known state, widen the search radius to compensate for uncertainty, reduce the matching frequency to lower load.
• User impact: slightly worse matches, slightly longer waits.
• Exit: automatic on lag recovery.

Mode 3 — Essential only.

• Trigger: severe capacity loss or a regional failure.
• Behaviour: accept and match requests; disable everything else — scheduled bookings, promotions, ratings, receipts generated in-line, non-critical notifications. Shed lower-priority traffic at the edge.
• User impact: visible feature loss, with a status message.
• Exit: manual, after verification, because entering was a significant event.

The prerequisite: prioritisation defined in advance

Modes require knowing which traffic matters most, classified before the incident and propagated as a request attribute, because it cannot be invented under pressure:

• By journey — completing a trip outranks browsing.
• By user state — someone mid-transaction outranks a new arrival.
• By request type — a non-retryable write outranks a refreshable read.

The operational requirements

• Each mode must be enterable without a deployment — a feature flag or a control-plane setting. Deploying during an incident is far too slow.
• Entry and exit must be logged and alerted, and visible externally, so support and customers know why behaviour changed.
• Each mode must be tested, or it is documentation. A mode that has never been entered has an even chance of being broken.
• Exit criteria must be defined, or the system stays degraded long after the cause is fixed — which is a surprisingly common outcome.
• Degraded mode must be cheaper, not more expensive. A fallback that costs more amplifies the incident.

What a strong answer adds

Naming the mode that does not exist: there is no acceptable degradation for taking a payment incorrectly or for authorising the wrong person. Degrade reads freely, degrade writes cautiously, never degrade correctness for money or access.