Один сбой Redis остановил систему кредитного скоринга на полчаса. Допустимый лимит простоя за месяц закончился за один инцидент. Тогда команда решила перейти на Hazelcast. Тут данные хранятся сразу в нескольких копиях, а при отказе одного сервера система продолжает работать. Следующая поломка оборудования уже прошла незаметно для пользователей. Но у новой системы нашлись свои проблемы. Сохранение данных после перезапуска пришлось настраивать самостоятельно, некоторые библиотеки нельзя было нормально подключить, а часть нужных функций оказалась платной. Автор разбирает переход с Redis на Hazelcast, настройки системы и проблемы, которые обнаружились уже во время работы. Несмотря на удачный результат, теперь команда рассматривает еще одну замену.

Designing Data Intensive Applications, 2nd edition by Martin Kleppmann Обзор первого издания книжки с кабанчиком был одним из первых книжных обзоров на моём канале (если кому интересно, как это выглядело почти 3 года назад — вот ссылка на пост). Я эту книгу всегда любил и высоко ценил, перечитывал несколько раз, поэтому после новости о переиздании был очень рад. Конечно, я добрался до неё не сразу, но и затягивать не стал. Мотивацию читать второго кабанчика объяснить очень просто — на мой вкус, это одна из лучших книг по system design (и точно лучшая книга по проектированию приложений с большим потоком данных). ⭐️ О чём книга Книга посвящена построению надёжных, стабильных, отказоустойчивых приложений, которые интенсивно работают с данными. Работа включает в себя чтение, запись, хранение и так далее. Также книга покрывает многие аспекты построения распределённых систем, важные для работы с данными. В книге раскрываются следующие темы: ➡️ Как эффективно хранить и получать данные ➡️ Как обеспечивать сохранность данных (репликация, шардирование) ➡️ Детальный разбор устройства транзакций ➡️ Особенности работы с данными в распределённых системах ➡️ Batch & Stream processing: особенности выстраивания ⭐️ 3 идеи из книги 🟡Сейчас на рынке появляются HTAP-базы данных (гибрид транзакционной и аналитической модели). Но часто оказывается, что «под капотом» у них всё так же две разные системы: одна для транзакционной обработки, а вторая — для аналитической. Это важно понимать при анализе конкретного решения. 🟡Для многих БД непрактично останавливать весь процесс работы с целью резолва конфликта данных, поэтому они сохраняют обе версии и продолжают работать. При следующем запросе этих данных такая база возвращает обе версии клиенту, предоставляя ему самому выбрать метод решения конфликта. 🟡Ошибки сети довольно редки, но приложение должно уметь справляться с ними. Особенно это важно в сложных геораспределённых системах, где сеть будет лагать и отваливаться гораздо чаще, чем в каком-нибудь небольшом кластере кубера, развёрнутом в одном ЦОДе. Этими ошибками часто пренебрегают, из-за чего вылезают неприятные баги. ⭐️ Мои впечатления Второй кабанчик стал намного лучше для меня как для читателя. Во-первых, новая структура книги кажется мне более логичной и последовательной: читать было комфортнее, темы расположены так, чтобы не приходилось забегать вперёд (в первом кабанчике это было частой проблемой). Во-вторых, сам контент был изрядно переписан и стал более «удобоваримым». Мне показалось, что книгу стало проще понимать (особенно в части разных весёлых аномалий). Хотя, может, это я просто стал умнее :) DDIAv2 в моём личном рейтинге стала достойной преемницей первой части и по-прежнему будет занимать место в топе лучших технических книг, которые я когда-либо читал. Рекомендую, даже если вы читали первую часть — вас ждёт много интересных открытий и инсайтов. Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте. А для тех, кто хочет читать с большей пользой, у меня есть статья с описанием моего процесса чтения и упражнениями. ➖➖➖➖➖➖➖➖➖➖➖ 📝 @ulshinblog 💬 Бэкап канала в Max