Данные кэшируются везде -  от фронтенда до бэкенда!

#перевод_для_канала_itarchitecture

Эта диаграмма иллюстрирует, где мы кэшируем данные в типичной архитектуре.

Вдоль этого потока лежит несколько слоев:

🔹 1. Клиентские приложения: HTTP-ответы могут быть кэшированы браузером. Мы впервые запрашиваем данные по HTTP, и они возвращаются с политикой истечения срока действия в заголовке HTTP; мы снова запрашиваем данные, и клиентское приложение сначала пытается получить данные из кэша браузера.

🔹 2. CDN: CDN кэширует статические веб-ресурсы. Клиенты могут извлекать данные с ближайшего узла CDN.

🔹 3. Балансировщик нагрузки: Балансировщик нагрузки также может кэшировать ресурсы.

🔹 4. Инфраструктура обмена сообщениями: Брокеры сообщений сначала хранят сообщения на диске, а затем потребители получают их по мере необходимости. В зависимости от политики хранения данные кэшируются в кластерах Kafka в течение определенного периода времени.

🔹 5. Сервисы информационной системы: В сервисах есть несколько уровней кэша. Если данные не кэшируются в кэше центрального процессора (CPU), сервис попытается получить данные из памяти (RAM). Иногда сервис имеет кэш второго уровня для хранения данных на диске.

 🔹 6. Распределенный кэш: Распределенный кэш, такой как Redis, хранит пары ключ-значение для нескольких сервисов в памяти. Это обеспечивает гораздо лучшую производительность чтения/записи, чем в базах данных.

🔹 7. Полнотекстовый поиск: Иногда нам нужно использовать полнотекстовый поиск, такой как Elastic Search для поиска документов или поиска в логах. Копия данных также индексируется в поисковом движке.

🔹 8. База данных: Даже в базе данных у нас разные уровни кэшей:
- WAL(Write-ahead Log - упреждающая журнализация): Данные записываются в WAL перед созданием индекса B-tree
- Buffer pool: Область памяти, выделенная для кэширования результатов запроса
- Materialized View: Предварительно вычисляет результаты запросов и хранит их в таблицах базы данных для лучшей производительности запросов
- Transaction Log: Логирует все транзакции и обновления базы данных
- Replication Log: Используется для записи состояния репликации в кластере баз данных

👉 Вопрос к вам:
Как мы можем гарантировать, что конфиденциальные пользовательские данные будут полностью удалены из систем, если данные кэшируются на многих уровнях?

Ответ:
Системы кэширования обычно работают с учетом трех временных факторов:
- промежуток времени;
- повторная валидация;
- очистка.
В зависимости от необходимости мы можем стереть данные.
Кроме того, кэшем можно управлять на стороне пользователя.