#статья #practices #medium #en
Все, что вам нужно знать о кэшировании
Everything you need to know about Caching — System Design
Когда вы делаете прототип (MVP, эксперимент), важна скорость разработки. Вы реализовываете не самые эффективные алгоритмы, не самую надежную архитектуру.
В какой-то момент вы запускаете свою функциональность и, если с продуктовой точки зрения все хорошо, то у вас появляются пользователи, потом еще пользователи, потом еще.
Вы начинаете упираться в свои быстрорешения, которые вы принимали в самом начале пути. (PS: и это нормально). Но теперь приоритеты немного меняются, вам все также нужно сохранять скорость деливери, но при этом и выдерживать рост нагрузки.
На этом этапе появляется несколько вариантов, из которых нужно будет выбирать (а на самом деле комбинировать):
1) Начать переписывать (переосмысливать) части проекта (но может сильно затормозить деливери)
2) Начать заваливать деньгами - железом (но может оказаться сильно дорого)
3) Попытаться минимальными усилиями выжать из текущих решений максимум (добавит времени, но деливери со временем будет падать)
И, если первые два пункта, вроде бы, понятны, то вот с третьим нужно чуть больше конкретики.
Обычно, самое правильное и менее костыльное решение - это кэширование (PS: один из моих самых любимых вопросов на собеседовании - это реализовать LRU кэш).
С помощью кэширования можно существенно снизить нагрузку на базы данных или сторонние сервисы.
В статье рассматриваются основные методы и подходы для организации кэширования.
https://levelup.gitconnected.com/everything-you-need-to-know-about-caching-system-design-932a6bdf3334
Все, что вам нужно знать о кэшировании
Everything you need to know about Caching — System Design
Когда вы делаете прототип (MVP, эксперимент), важна скорость разработки. Вы реализовываете не самые эффективные алгоритмы, не самую надежную архитектуру.
В какой-то момент вы запускаете свою функциональность и, если с продуктовой точки зрения все хорошо, то у вас появляются пользователи, потом еще пользователи, потом еще.
Вы начинаете упираться в свои быстрорешения, которые вы принимали в самом начале пути. (PS: и это нормально). Но теперь приоритеты немного меняются, вам все также нужно сохранять скорость деливери, но при этом и выдерживать рост нагрузки.
На этом этапе появляется несколько вариантов, из которых нужно будет выбирать (а на самом деле комбинировать):
1) Начать переписывать (переосмысливать) части проекта (но может сильно затормозить деливери)
2) Начать заваливать деньгами - железом (но может оказаться сильно дорого)
3) Попытаться минимальными усилиями выжать из текущих решений максимум (добавит времени, но деливери со временем будет падать)
И, если первые два пункта, вроде бы, понятны, то вот с третьим нужно чуть больше конкретики.
Обычно, самое правильное и менее костыльное решение - это кэширование (PS: один из моих самых любимых вопросов на собеседовании - это реализовать LRU кэш).
С помощью кэширования можно существенно снизить нагрузку на базы данных или сторонние сервисы.
В статье рассматриваются основные методы и подходы для организации кэширования.
https://levelup.gitconnected.com/everything-you-need-to-know-about-caching-system-design-932a6bdf3334