Классика. В Node.js/TS стеке встречал похожее: Redis через Nginx, явно добавляешь Cache-Control: no-store на /api/balance — и думаешь что порядок. Потом оказывается что в конфиге Nginx proxy_cache_valid 200 1h; перекрывает заголовки ответа.

Ещё вариант: load balancer без sticky sessions + in-memory кеш на ноде. Пользователь попадает на разные инстансы — видит разные значения. TTL в 60 секунд тут вообще не при чём, проблема в том что кеш не общий.

Решение которое спасало: вынести весь state-чувствительный кеш в Redis, запретить Nginx кешировать /api/* целиком.

Ответ: CDN или reverse proxy (Nginx) кеширует ответ API.

Типичная строка-виновник в конфиге Nginx: proxy_cache_valid 200 24h;

Или в ответе API отсутствует заголовок: Cache-Control: no-store

Что происходит: 1. Пользователь обновляет баланс. 2. Ваш сервис корректно отдает новое значение. 3. Но Nginx/CDN перед сервисом закешировал старый ответ. 4. 99% запросов не доходят до вашего сервиса вообще. 5. Пользователь видит вчерашний баланс.

Балансировщик какой-нить, хреново настроенный

Не перед нашим, а перед вашим )))

первая мысль - nginx или CDN с своим cache-valid на сутки перед приложением, игнорирует Cache-Control хедеры от бэка. «один конфиг» - звучит как proxy_cache_valid или аналог у reverse proxy. таких задач боялся на собесах - они про понимание всего стека, а не только кода приложения. готовился к debug-сценариям через jobpath.world перед парой собесов именно поэтому

Честно сразу полез гуглить. Было предположение на какое-то прокси перед сервисом. Гугл подсказал на cdn сервис. Типа там по умолчанию конфиг на 24 часа иде. И в итоге для приложения вроде все нормально 60 секунд. А при взаимодействии с внешним миром вчерашний хлеб

Мне кажется проблема в том что формат даты в конфиге не учитывает часовые пояса.