Если вопрос про инвалидатор, то нет, так как если он сломается, то у нас все еще есть ttl, который мы можем если что быстро понизить его до того значения, которое было до инвалидатора. А если речь про фасад, то да, является, но тут намечается холивар на тему: что лучше единая надежная точка отказа, которой фултайм занимается команда профессионалов или 300 маленьких, которые делаются по остаточному принципу, а если учесть, что вполне вероятна ситуация, когда нужно доработать все 300, то скоуп любой задачи улетает в космос
Это реально большая проблема, но мы стараемся проектировать системы таким образом, чтобы событие из мастер системы уходило только после того как данные в ней реально обновились
Мы как минимум перешли с Memcached на Valkey, благодаря чему у нас данные реплицированны. Это как раз про сложность которая дает надежность. Но в общем случае да, согласен чем проще тем надежнее. Но есть же история, что сначала риск принимается, так как он небольшой, а минимизировать его сложно, а потом делается какой-то механизм для снижения этого риска
Нет, мы же кешируем в in-memory достаточно редко обновляемые данные, за 200мс устареет один ключ из нескольких десятков тысяч. А для той, части данных обновляется редко но крупными пачками, действительно данные будет не актуальными, но сотни миллисекунд, а не десятки минут.
Если вопрос про инвалидатор, то нет, так как если он сломается, то у нас все еще есть ttl, который мы можем если что быстро понизить его до того значения, которое было до инвалидатора. А если речь про фасад, то да, является, но тут намечается холивар на тему: что лучше единая надежная точка отказа, которой фултайм занимается команда профессионалов или 300 маленьких, которые делаются по остаточному принципу, а если учесть, что вполне вероятна ситуация, когда нужно доработать все 300, то скоуп любой задачи улетает в космос
А, да, в случае с memcached мы это так и решали, а при переходе на valkey написали для него модуль, который это поведение повторяет
Это реально большая проблема, но мы стараемся проектировать системы таким образом, чтобы событие из мастер системы уходило только после того как данные в ней реально обновились
Мы бы рады, что-то готовое использовать, но в полной мере не подошло ничего, чему собственно и посвящена половина статьи
Мы как минимум перешли с Memcached на Valkey, благодаря чему у нас данные реплицированны. Это как раз про сложность которая дает надежность. Но в общем случае да, согласен чем проще тем надежнее. Но есть же история, что сначала риск принимается, так как он небольшой, а минимизировать его сложно, а потом делается какой-то механизм для снижения этого риска
Нет, мы же кешируем в in-memory достаточно редко обновляемые данные, за 200мс устареет один ключ из нескольких десятков тысяч. А для той, части данных обновляется редко но крупными пачками, действительно данные будет не актуальными, но сотни миллисекунд, а не десятки минут.