Проектирование интеграций SMM API, которые переживают сбои

Первая версия любой интеграции с API исходит из счастливого пути: вы отправляете запрос, получаете ответ, заказ размещён. Прод учит обратному. Сети рвутся, эндпоинты выходят за таймаут, а самый опасный сбой неоднозначный: запрос, который мог и успеть, и не успеть пройти, прежде чем соединение оборвалось. Проектирование под эту неоднозначность и есть вся суть работы.

Идемпотентность основная защита. Прикрепляйте уникальный ключ к каждому запросу на заказ и заставьте сервер трактовать повтор этого ключа как ту же операцию, а не новую. Теперь повтор после таймаута безопасен: если оригинал прошёл, вы получаете существующий заказ, а не дублирующее списание. Без этого каждый повтор азартная игра с вашим балансом.

Наслаивайте сверху повторы с backoff. Временные ошибки (лимит 429, 503, сброс сети) следует повторять с нарастающими задержками и ограничением, а не долбить мгновенно. Постоянные ошибки (некорректный запрос 400, ответ о недостатке баланса) должны падать быстро и всплывать к человеку, потому что их повтор лишь тратит время и скрывает настоящую проблему.

Наконец, сверяйте. Логируйте каждый запрос и ответ с его ключом идемпотентности и ID заказа и запускайте периодическую задачу, сравнивающую ваши записи с состояниями заказов в панели. Сверка это то, что ловит заказ, который прошёл в панели, но не записался у вас. API SocialGO возвращает единообразные ID и статусы заказов именно для того, чтобы эту петлю было просто выстроить: в этом разница между автоматизацией, которой доверяешь, и той, за которой нянчишься.