Как департамент утилизации CPU превратился в департамент экономии железа, выдерживающий нагрузку в 1 млн RPS

Хорошая статья от Ozon на тему кэширования на примере создания сервиса product-facade, который будет единым кешом над всеми мастер-системами в Ozon. Сервис получился нагруженным (1 mln rps, 350 Gb/s в пике на раздачу). Интересно почитать про различные стратегии работы с кешом по мере нарастания изощренности

• lazy caching (с чего все начиналось) и дальше вопросы инвалидации кеша с версионированием, тегами, TTL, событиями из Kafka для инвалидации
• **read-through caching
• write through caching** Дальше интересная часть про выбор локального или внешнего хранилища кешей и отчего это зависит, тут прямо хорошо разобраны дизайн решения и плюсы и минусы каждого подходов и как и для чего их комбинировать. А дальше хорошо про борьбу за hitrate и стратегии вытеснения кеша (LRU, LFU, Segmented LRU) и что делать с thundering herd problem. И напоследок немного про то, как кешировать решение полностью обмазанное кешами:)

В конце авторы выдают хороший чеклист из вопросов, которые надо задать себе перед тем, как начать кешировать

• Безопасно ли использовать кэшированное значение?

• Какое допустимое время жизни объектов в кэше?

• Допустимы ли задержки в обновлении кэша при изменениях в данных или его необходимо инвалидировать сразу?
• Как часто изменяются данные?
• Каков ожидаемый объем кэшируемых данных?
• Какие ожидаются сценарии запросов (пользовательское поведение клиентов)?
• Ожидаются ли горячие ключи, на которые будет приходиться основная читающая нагрузка?
• Эффективно ли будет кэширование?

В общем, с инженерной точки зрения статья точно хороша. Я при чтении вспоминал свои вьетнамские флешбеки с кешированием и было прямо приятно некоторые моменты прочитать в хорошо описанном виде. Но вот с точки зрения дизайна архитектуры и взаимодействия команд мне показалось, что отдельный отдел, который кеширует все данные за всех - это решение, которое работает на определенном масштабе и которое плохо масштабируется на крупную организацию. Мы получаем аля DWH, но не сзади, а спереди:) В итоге, ответственность за попадание в кеш, настройку кеша, получение эффективно данных из источников и правильную инвалидацию приходится на централизованную команду, а должно по идее быть ответственностью самих продуктовых команд.

#Software #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #Management