Прод упал из-за кеша. И это лучший урок по архитектуре

В три часа ночи прод упал. Не из-за бага в бизнес-логике. Не из-за DDoS. Из-за кеша. Запрос, который в тестах отрабатывал 12 миллисекунд, в проде зависал на 4.2 секунды и рвал connection pool. Мы перепроверили индексы, переписали тяжелые JOIN, прогнали EXPLAIN ANALYZE. Ноль изменений. Потом заглянули в APM-метрики и увидели аномалию: приложение стабильно съедало 96% heap, хотя RPS был в три раза ниже пикового. Сборщик мусора не успевал, начинались stop-the-world паузы, таймауты сыпались каскадом. Корень оказался банален: мы кешировали результаты сериализации JSON-объектов в Redis, не ограничивая TTL и не считая размер пейлоада. Ключи копились. Память не освобождалась. Мы думали, что оптимизируем производительность, а на деле копали яму под собственную инфраструктуру. Решение заняло пятнадцать минут: ограничить максимальный размер кеша, включить сжатие на уровне драйвера, вынести тяжелую сериализацию в асинхронную задачу с приоритетом. Но урок остался на годы. Высоконагруженная система падает не от архитектурной сложности. Она падает от молчаливых накоплений: незакрытых соединений, растущих логов, кеша без срока жизни, очередей без dead-letter. Чистая архитектура — это не соблюдение границ на схеме. Это изоляция боли при изменениях. Если замена одного компонента требует переписывания трёх сервисов — границы проведены по логике, а не по частоте изменений. Проверяйте не только то, что видно в логах. Проверяйте то, что тихо растёт в фоне. И ставьте лимиты на всё, что копится. Наблюдаемость — это не дашборды. Это способность задавать системе новые вопросы, не разворачивая новый код. Без неё вы слепы. А система, которую вы не видите, рано или поздно ударит.