Как следует организовать работу асинхронного TTL-кэша, если он обращается к внешнему Redis-кэшу, который может отвечать долго?

Используйте асинхронный Redis-клиент, короткий бюджет ожидания и ограниченную конкурентность. Cache miss и недоступность кеша — разные состояния, а fallback должен защищать основную систему от перегрузки.

Для производных данных при таймауте иногда допустимо обойти кеш; для авторизации или критичного состояния такое правило нельзя применять вслепую. Добавьте single-flight, circuit breaker и метрики latency/errors. Не удерживайте глобальный lock во время долгого сетевого ожидания. TTL задавайте на сервере Redis, а отмену и поздние результаты обрабатывайте явно.