IOSOR

IOSOR База знаний

DLR, latency и failover: одна правда для продукта и финансов

Объедините delivery receipts, полосы latency и политику failover, чтобы продукт, ops и финансы не спорили об одном webhook — с prepaid-честностью.

Продукт хочет конверсию. Финансы — предсказуемые дебеты. Ops — слово статуса, одинаковое в дашборде, webhook и инвойсе. Когда DLR, latency и failover живут в трёх силосах, каждый инцидент становится спором о словаре — prepaid горит, пока команды спорят.

IOSOR — white-label prepaid messaging с одним словарём статусов по каналам: client-safe ошибки, без брендового театра. Около USD 1 000+ месячного platform usage экспорт terminal-status, полосы latency по коридорам и debit каждой failover-попытки становятся материалом коммерческого review. Сначала evidence, потом scale.

Одна таблица правды для руководства

Слой Вопрос продукта Вопрос финансов Общий артефакт
DLR Пользователь получил? Delivery billable? Terminal status + timestamp
Latency Внутри SLA? N/A, если retries не множат debit Corridor p95/p99
Failover Какой path победил? Сколько attempts debited? Attempt log + correlation ID

Если на все три нельзя ответить из одного export — одной правды ещё нет. Руководство не должно собирать месяц из трёх таблиц. Общий артефакт на слой — самый дешёвый способ остановить спор о словаре.

Подключение DLR, которое выдерживает аудит

  • Signed или authenticated inbound events
  • Idempotent consumers с dedupe keys
  • Correlation send → status → ledger
  • In-product проверка недавней доставки

Неподписанные webhook и неидемпотентные consumer превращают retries в дубли тикетов и дубли debit. См. операционный гайд по доставляемости SMS и не доставлено, отклонено, истекло. Каталог live без DLR-correlation к ledger — обещание, которое финансы не защитят.

Полосы latency, а не vanity-средние

Отслеживайте accepted → submitted → delivered по коридорам. OTP-конверсия зависит от географии; глобальное среднее прячет сломанный рынок. При деградации latency решайте retry vs failover vs stop с named owners — не надеясь. Режьте p95/p99 в недельном отчёте, чтобы слабый коридор не прятался за мировым средним. Latency без владельца становится неоплаченным циклом retry.

Failover с prepaid-дисциплиной

Failover спасает пользователей — или сжигает кошельки:

  1. Лимит автоматических попыток на сообщение.
  2. Разделите user resend и system failover.
  3. Никогда не failover в записи каталога in setup.
  4. Задокументируйте debit rules на попытку.

Mock-маршруты в production failover chain — не страховка. Voice/SMS fallback: голосовые алерты и OTP-fallback. Product и finance должны выгрузить все попытки одного сообщения и сверить correlation ID. Ограничьте retry до того, как failover станет дорогим циклом на мёртвом коридоре.

Красные флаги

  • Delivered и sent взаимозаменяемы в UI
  • Failover-попытки невидимы финансам
  • Mock-маршруты в production failover chains
  • Слова статуса различаются webhook vs invoice
  • Только скриншоты как proof
  • Failover обещан при каталоге in setup
  • Upstream-бренды в client-facing ошибках

Старт с IOSOR

Возьмите один коридор и один тип сообщения. Выгрузите terminal DLR прошлой недели в общий словарь продукта и финансов, затем проведите один correlation ID через staging, failover и списание с кошелька. Сымитируйте смену пути и сравните, что увидел пользователь, с тем, что списал ledger. Почините лейбл Delivered, если финансы ещё держат retry или failover-debit.

Итог IOSOR

Продукт и финансы читают один DLR, одни часы latency и один исход failover на том же correlation ID. Списание без статуса, который видит пользователь, — ложь.

Делайте: опубликуйте таблицу правды и выгрузите её. Не делайте: пусть продукт выдумывает статус, который финансы не соберут, или прячет failover-debit за зелёным бейджем.

Был ли материал полезен?

Связанные гайды