Кэш у края как сброс давления, а не волшебная память

Кэш перед приложением означает: иногда отвечаем, не доходя до origin. В модели это фильтр повторной работы — меньше сообщений в дорогом поддереве, ниже утилизация там, bottleneck смещается — часто к проверке данных, сериализации или самому кэшу.

Когда эффект правда есть

При всплесках read-heavy трафика высокий hit ratio снижает среднюю задержку на горячем пути, но p99 может определяться промахами или штормами вытеснения. Симулятор подталкивает называть эти режимы, а не сводить всё к одному throughput.

На что смотреть вместе

• Сопоставлять число пересланных запросов с допущениями по hit ratio в конфиге — расхождение намекает на устаревшую политику.
• Следить за fan-out: кэш может скрыть перегрузку, пока origin не проснётся холодным.

Попробуйте

Поставьте уровень кэша между входом и API с БД, затем меняйте «жёсткость» подразумеваемого TTL в панели и сравнивайте процентили задержки и ошибки с прогоном без этого хопа.