skip to content

For a marketplace notification service, how would you decide when an undelivered push notification should fall back to email or SMS?

level: principalimportance: nice to knowfreq 28%

answer

  1. no single rule, a per-type policy
  2. urgency and value versus cost
  3. the push may still arrive
  4. consent limits the chain
  5. who pays when someone abuses it

basics

~20 s

Decide per notification type by weighing urgency and value against cost, intrusiveness and duplicate risk: fall back immediately when no valid push token exists, after a short timeout only for urgent high-value messages, and never onto a channel the user has not consented to.

solid answer

~50 s

There is no single rule, so I would make fallback a **per-type policy** driven by urgency, value and cost. If the user has **no valid push token**, fall back right away. If the push was accepted but shows no delivery signal within a window, fall back only for **urgent, high-value** messages such as a payment problem or a login code, because SMS is far more expensive and intrusive, and the push may still arrive and create a duplicate. Low-value messages get no fallback, or at most a later email digest. Fallback must respect **consent**: no SMS without SMS permission. Paid fallback also needs **abuse limits**, per user and per destination, because code requests can be triggered to run up SMS bills. I would validate the policy with a **holdout** that measures the incremental reach each fallback buys, and keep the rules as data that product owners change within guardrails.

go deeper

for a junior

Recall that push can fail silently and that a notification can be retried on another channel, but only when the user allowed that channel.

for a middle

Explain the triggering signals: no token, rejected token, and accepted-but-no-delivery, and why only the last one risks a duplicate.

for a senior

Show the operational guardrails: per-channel idempotency, cancellation on late delivery, spend budgets and abuse limits on paid fallback.

for a principal

Own the policy trade-off per notification type, prove incremental reach with holdouts, and set the ownership split between product-owned rules and platform-enforced guardrails.

## The decision being made A marketplace can reach a user by **mobile push**, **email** or **SMS**. Push is cheap and immediate but unreliable: tokens become stale when apps are reinstalled, devices are offline, and users disable notifications. **Channel fallback** means trying another channel when the first one does not get through. Done blindly, it multiplies cost and annoys users with the same message twice; done never, important messages silently vanish. The decision has no single correct answer, which is why it is a lead-level question. ## The factors to weigh - **Urgency.** Does the message lose its value within minutes (a login code) or days (a review request)? - **Value of reach.** What happens if the user never sees it: a failed payment and a cancelled order, or nothing much? - **Cost.** SMS is typically priced per message and far above push or email, and prices vary widely by destination country. - **Intrusiveness.** SMS interrupts; a user who receives low-value texts is likely to opt out of everything. - **Duplicate risk.** A push that looked undelivered may still land later, so the user sees both. - **Consent.** Fallback may only use channels the user permitted for that category, and SMS often needs explicit permission. ## Signals that trigger fallback Fallback decisions depend on what the service actually knows: 1. **No channel available.** No registered push token, or the platform push service reported the token invalid. Falling back immediately is safe; there is nothing to duplicate. 2. **Push rejected.** A permanent error from the push service for this device. Treat like case 1 and clean up the token. 3. **Push accepted, no delivery or open signal within a window.** Ambiguous. The device may be offline and receive it later. Fall back only if the message is urgent enough to justify a possible duplicate. 4. **User preference.** Some users choose 'SMS for order updates'; that is routing, not fallback, and it is applied first. In-app delivery receipts and presence are a separate concern; the fallback policy only consumes whatever delivery signal is available. ## A policy table | Notification type | Primary | Fallback | Trigger | |---|---|---|---| | Login or payment code | SMS or push, per user choice | the other one | no token, or no delivery within about a minute | | Payment failed | push | email, then SMS | no delivery within a set window | | Order shipped | push | email | no token only | | Price drop, social update | push | none, or email digest | never paid fallback | | Marketing campaign | email | none | never | The windows and chains here are illustrative; the point is that each type states its chain, its trigger and its ceiling. ## Guardrails - **Abuse limits.** Anyone who can trigger a code can make the service send SMS to arbitrary numbers, including costly ones, to run up charges. Per-user, per-number and per-destination-prefix rate limits, plus anomaly alerts on SMS spend, contain this. - **Spend budgets.** A daily SMS budget per notification type, with alerts, stops a misconfigured rule from becoming an expensive incident. - **Idempotency per channel.** Each channel's send has its own key, so the fallback is not blocked by the push record and is not itself sent twice. - **Cancellation.** If a delivery signal for the push arrives before the fallback fires, cancel the pending fallback. ## Deciding with evidence It is tempting to assume fallback helps. A better approach is a **holdout experiment**: for a slice of users, suppress the fallback and compare outcomes such as payment recovery, sign-in success or order completion. The difference is the **incremental reach** the fallback buys, and it can be weighed directly against its cost and its effect on opt-out rates. Some fallbacks prove essential; others mostly duplicate messages users would have seen anyway. ## Ownership Routing and fallback rules work best as **data**, a table owned jointly by product and the notification platform, rather than as code in each feature. The platform enforces the guardrails (consent, caps, budgets, abuse limits) that no rule can override, and product owners adjust chains and windows within them. That split lets teams move quickly without being able to create a costly or consent-breaking rule by accident.

  • How would you measure whether SMS fallback for failed-payment notices is worth its cost?
    Run a holdout: for a random slice of affected users, skip the SMS fallback and keep everything else the same. Compare payment recovery rate and revenue between the groups, and subtract the SMS spend and any rise in opt-outs. If recovered revenue clearly exceeds cost, keep the fallback; if the groups look alike, the push and email were already reaching those users.
  • What should happen if the push delivery signal arrives after the fallback timer has been scheduled but before it fires?
    The fallback should be cancelled. The scheduled fallback is keyed to the original message, and a delivery signal for that message marks it delivered in the send record; the fallback job checks that state just before sending and skips if the message was delivered. This removes most duplicates caused by slightly late push delivery.

saying these in an interview costs you the question

  • Always fall back to SMS when a push shows no delivery signal.
  • A missing delivery signal proves the push was never delivered.
  • Fallback may use any channel the user has a contact point for.
  • SMS fallback for codes carries no abuse or cost risk.
  • Fallback always improves outcomes, so there is no need to measure it.