Рубрика «idempotency»

Последние несколько лет я собираю платёжные интеграции для продуктов, которые банки вежливо называют «high-risk». Под «high-risk» обычно попадают: iGaming / betting dating (особенно adult dating) crypto onboarding / exchange ramps nutra / supplements travel / subscriptions с free-trial моделью forex / trading / микрозаймы

Один проект — подписочный сервис на NestJS/TypeORM с рекуррентными списаниями через SOAP-шлюз прибалтийского банка-эквайера. Второй — кредитный продукт на Python/FastAPI, где под капотом крутятся три локальных PSP одновременно. Обе системы живут в проде, обе списывают реальные деньги с реальных карт, и обе научили меня вещам, которых нет ни в одной документации шлюза.

Читать полностью »

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно 3 ответа провайдера с 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Читать полностью »

В какой-то момент на старте в нашем data-сервисе (известная в узких кругах аналитическая платформа для селлеров WB/Ozon «Таблички») стало возникать много фоновых работ: ETL‑сенсоры, сложные API‑запросы к маркетплейсам, пересчёты витрин, обслуживание «сервисных» задач. К тому же добавилась потребность сгладить пики нагрузки на БД, растянув поступающую нагрузку во времени. Хотелось:

  • без отдельного брокера (Rabbit/Kafka) на старте,

  • с горизонтальным масштабированием воркеров,

  • с понятным «забрал задачу → обработал → отметил результат»,

  • чтобы падение воркера не превращало задачи в «вечные зомби»,

  • Читать полностью »

https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js