👨💻 Кэширование в три слоя — спасение базы данных
База данных имеет лимит количества запросов в секунду, который она может обработать. При миллионах запросов в час этот лимит будет достигнут независимо от того, насколько хорошо написан код. Решение одно: кэшировать агрессивно.
Неправильный подход это кэшировать все и везде без логики. Правильный подход это иметь стратегию кэширования с разными слоями.
Первый слой: память приложения
MemoryCache в .NET работает очень быстро, потому что данные лежат в памяти одного процесса. Здесь кэшируются часто запрашиваемые данные с коротким временем жизни. Профили пользователей, настройки, статические справочники. TTL может быть 30 секунд или минута.
Второй слой: распределенный кэш
Redis или Memcached. Когда приложение запущено на нескольких контейнерах, они должны видеть одни и те же данные. Если один контейнер кэшировал профиль пользователя, остальные должны получить его без запроса в БД.
Третий слой: кэширование ответов
Некоторые API ответы не зависят от пользователя и могут быть закэшированы целиком. Если GET /api/countries возвращает список стран, это можно кэшировать на час, потому что страны не меняются часто.
На практике такая архитектура может снизить нагрузку на базу данных на 80 процентов. Просто потому, что большинство запросов идут в кэш, а не в БД.
Ключ в том, чтобы знать, какие данные и как долго кэшировать. Не нужно хранить в кэше пользовательские данные, которые меняются каждую секунду. Нужно кэшировать данные, которые стабильны и часто запрашиваются.
📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта
В этом посте были ссылки, но мы их удалили по правилам Сетки
