Усунення дублікатів вхідних MO-подій на рівні API-шлюзу

Повторні спроби передачі даних з боку мережевих вузлів часто призводять до дублювання вхідних MO-подій, що спричиняє подвійне списання коштів з балансу та помилкові відповіді. Щоб уникнути цього, необхідно впровадити дедуплікацію на рівні API-шлюзу за допомогою створення унікальних цифрових відбитків повідомлень. Такий підхід дозволяє відсікати ідентичні запити ще до початку їх обробки в основній системі.

Концепція фільтрації вхідного потоку повідомлень

Вхідний мобільний трафік через вебхуки часто надходить кількома пачками через повторні спроби передачі з боку мережевих вузлів. Для операторів платформ із передоплатою відсутність перевірки на вході викликає подвійну тарифікацію та помилкові відповіді клієнтам. IOSOR реалізує жорстку дедупликацію на рівні API-шлюзу ще до запуску основних бізнес-процесів.

Атомарні блокування Redis та створення цифрових відбитків

Для швидкого пошуку дублікатів шлюз формує унікальний криптографічний хеш з номера відправника у форматі E.164, віртуального номера призначення, часового вікна та тіла запиту. Шлюз робить атомарний запит у Redis із ключем і TTL на шістдесят секунд. Якщо ключ існує, шлюз зупиняє обробку та повертає HTTP 200 OK без навантаження на базу даних.

Захист передоплатних рахунків від подвійних списань

Фінансова архітектура вимагає бездоганної цілісності транзакцій. Без захисту на шлюзі лавина повторних подій може спричинити паралельні списання коштів з балансу. Платформа витримує стартовий ліміт у USD 20 для нових орендарів. Коли обсяг транзакцій досягає значень близько USD 1,000/month, неконтрольовані дублікати здатні серйозно спотворити реальну аналітику.

Розподіл черг та асинхронна передача на воркери

Успішно перевірена подія надходить до ізольованого обмінника RabbitMQ, розділеного за ідентифікаторами орендарів. Це гарантує, що піковий трафік одного клієнта не заблокує ресурси інших користувачів платформи. Воркери забирають повідомлення для розсилки вебхуків. Механізми JIT зв'язують віртуальні номери з профільними маршрутами одразу після першого унікального повідомлення.

Обробка збоїв вебхуків та повторні запити

Мережеві збої вимагають надійної логіки повтору разом з ідемпотентністю. Додаткові патерни описані в матеріалах повторні спроби вхідного вебхука, управління навантаженням доступне у Тиждень відновлення вхідного трафіку: відновлення MO через дроттлінг, а не но…, а захист фінансів розкрито у ідемпотентність, retry і гроші. Це гарантує стабільність платформи.

Почніть з IOSOR

У staging надішліть той самий MO двічі з одним message-id провайдера. Блокування шлюзу має поставити в чергу одну подію; споживач має спрацювати один раз. Експортуйте ключ блокування і відкинутого близнюка. Дві відповіді 2xx дозволені; два рядки inbox або два дотики гаманця — провал цієї роботи. Це стиснення черги на шлюзі, не буфер таймауту, не запис STOP у список і не стеля auto-reply.

Підсумок IOSOR

Дедуп MO на шлюзі — блокування за id події до черги. Один message-id, одна подія.

Робіть: візьміть блокування, тоді ставте в чергу. Не робіть: сподіватися, що inbox чи гаманець «склеять потім».