Девелоперы, просыпайтесь. Та безупречная интеграция, которую вы слепили? Она на грани краха от одного кэша — реальные люди без платежей, задержанные грузы или, хуже, дублированные списания, от которых клиенты разбегаются за ночь.
За 20 лет калифорнийских баталий я наохотился на таких призраков: это не редкость. Это норма — каждый API-шлюз, CDN и прокси норовит покэшировать всё подряд, не предупредив.
Почему продакшен вдруг возненавидел ваши вебхуки?
Staging — сплошная иллюзия. Там всё летает, потому что нет этих закалённых в боях шлюзов, которые кэшируют POST-запросы, чтобы сэкономить ресурсы, будто они конфетки. Переключаетесь в прод — и привет: сбои на ровном месте. У них логи орут 200 OK. У вас? Тишина. Задачи не запускаются, события испаряются.
Меня это прихватило. Два полных дня — да, оплачиваемые часы в трубу — на дебаг чужого вебхука, который группировал события статичными ключами идемпотентности. Хитрый бизнес-ход, да? Нет. Наследованный шлюз кэшировал эти одинаковые POSTы и штамповал 200-й, не дав нашим серверам моргнуть.
Логи их сервиса показывали 200 OK от нашего эндпоинта, но в наших логах соответствующая фоновая задача так и не запустилась.
Классика. Периодический сбой, который не воспроизвести локально. Каждый прокси в цепочке — чёрный ящик, и все улыбаются лживо.
А теперь циничный штрих: кто в выигрыше? Не вы. Продавцы шлюзов экономят за счёт кэширования всего подряд, стригут купоны на ваших задержках, пока ваша интеграция рушится. Доки зарыты в мелком шрифте — «кэш может применяться к не-GET» — но попробуйте найти среди хвастовства аптаймом.
Гуглили когда-нибудь ‘API caching broke my integration’?
Стоило бы. Форумы завалены этим кошмаром. Помните ранние дни CDN, когда Akamai кэшировала динамичные POSTы и уничтожала корзины в e-commerce? История повторяется, только теперь API-шлюзы — Kong, AWS ALB, кто угодно — «оптимизируют» без спроса.
Мой эксклюзив: с бумом serverless и edge-вычислений это взлетит. Lambda@Edge, Cloudflare Workers — кэш-машины с первого шага. Следующая интеграция не просто сломается — разлетится по континентам без логов. Запоминайте: к 2025-му половина бед с вебхуками уйдёт корнями в излишне ретивые эджи.
Но — поворот — не всё так мрачно. Мы починили. Жёстко.
Сначала навесили Cache-Control: no-store на эндпоинт. Каждому посреднику сигнал: не трогай, всегда свежак. Больше никаких заготовленных лжей.
Второе — и умнее — отказались от статичной группировки по идемпотентности. Ключи теперь уникальны для каждого события. Запросы получаются разными; кэш мимо.
Протестировали через прокси. Держит. Но инфраструктуре я больше не верю — она изменчива.
Короткий абзац для удара: относитесь к кэшированию как к SQL-инъекции. Без компромиссов в дизайне.
Теперь по сути, почему это всех водит за нос. HTTP-статус? Бесполезен сам по себе. 200 из кэша — пустой звук, если ваше приложение payload не увидело. Логи расходятся: отправитель доволен, получатель голодает. Добавите ретраи? Усилите дубли. Идемпотентность спасает — обычно — но статичные ключи зовут кэш на пир.
Видели в финтехе: пропущенные сделки. E-com: фантомные заказы. SaaS: несинхронизированные юзеры. Настоящие деньги, настоящая ярость.
А пиар-обёртка? Вендеры трубят «молниеносно быстро», умалчивая цену: быстро за счёт чего? Они рассчитывают, что девы не читали RFC 7234, где сказано, что POST можно кэшировать, если не запретить.
Как защитить API от кэш-гремлинов?
Шаг первый: заголовки везде. no-store, no-cache, must-revalidate — меняйте как пароли. Postman? Бесполезен; тестите curl через прокси.
Шаг второй: уникальные ключи. UUID на событие, с таймстампом. Группируйте потом в очереди, не на проводе.
Третий: аудит пайплайна. Проследите каждый хоп — от сервера до шлюза и CDN. Curl по каждому, grep ответы. Жестоко, но вскрывает лжецов.
Четвёртый — мой приём из ветклиники — синтетический мониторинг. Пингуйте эндпоинты мутированными пейлоадами по реальным путям. UptimeRobot или Datadog не катят; стройте свой.
Работёнка. Но пропустить? Так с
