Как мы уронили сервис и подняли его с помощью кэша

В одном из наших внутренних сервисов случилась беда: при расчёте проектов он начал падать с ошибкой памяти. Начали разбираться — оказалось, за один расчёт сервис макропараметров дёргался до 3000 раз. И каждый раз он честно ходил в базу, что‑то там искал, отдавал и в какой‑то момент просто не выдерживал.

Нужно было что‑то делать. И желательно без долгих переписываний.

✅Первая мысль — кэш
Обычно в таких случаях ставят MemoryCache: сохранили данные — при повторном запросе отдали из памяти. Но есть нюанс: логика кэширования ложится на разработчика. Нужно писать код, проверять, сохранять, думать, когда инвалидировать.

И тут мы наткнулись на OutputCache. Штука, которая появилась в .NET 8, и она работает хитрее: кэширует не просто данные, а целиком HTTP-ответ.

Как это выглядит⬇️
Прилетает запрос — OutputCache смотрит: а нет ли у меня уже готового ответа на точно такой же запрос? Если есть — сразу отдаёт, даже не дёргая контроллер и не выполняя бизнес-логику. Если нет — пропускает запрос дальше, а ответ сохраняет.

Звучит просто, но разница колоссальная:
— код не меняется вообще (ну почти),
— путь запроса становится короче,
— сервер меньше грузится.

Но есть подводный камень❤️‍🩹
OutputCache кэширует ответ целиком. Вместе с заголовками. А значит, если не настроить политики, можно случайно «склеить» разных пользователей и отдать одному — куки другого. Пришлось аккуратно прописать, что именно учитывать при формировании ключа кэша: параметры маршрута, query-параметры, а для POST-запросов — ещё и тело.

Что получили
〰️До внедрения: тяжёлый метод GetMacroVersionData за 7 минут разогревался до 12 секунд ответа.
〰️После: стабильные 32 миллисекунды на протяжении 15 минут.

И да, сервис перестал падать.

📎 Кстати, про управление кэшем
Чтобы сбрасывать устаревшие данные, мы повесили теги. В OutputCache есть такой механизм управления кэшем. Можно сбросить всё разом, можно только то, что связано с макропараметрами, можно — конкретные данные внутри. Удобно и гибко.