Парадокс книги «Designing Data-Intensive Applications» Мартина Клеппмана

Когда книга вышла в 2017 году, её дико расхайпили. «Книгу с кабанчиком» обсуждали в ИТ-шных книжных клубах, спикеры конференций постоянно добавляли её в список рекомендованной литературы, которую должен прочитать каждый уважающий себя бэкендер. И всё это подогревалось набирающим популярность System Design Interview.
Все эти «бигтеховские темки»: шардирование, репликация, потоковая обработка данных, аналитика – будоражили мозги обычных работяг, чья повседневная работа редко выходила за рамки перекладывания JSON-ов. «Вот он – ключ к безграничным возможностям по обработке данных» – так мотивировали себя многие, кто садился за эту книгу.
Эта книга, несомненно, большой сфокусированный труд об известной проблеме. Я такое люблю. Но, вспоминая сейчас свои эмоции от прочтения этой книги, я не могу сказать, что она как-то сильно на меня повлияла. И только прочитав её ещё раз во втором издании, которое вышло совсем недавно, я понял, почему.
Вот парадокс: книга, которую рекомендуют для подготовки к System Design Interview, не готовит к System Design Interview. Более того – она не учит ни создавать системы, ни подскажет простые решения. И при этом я считаю её фундаментальным трудом. Как так вышло?
Не подскажет простые решения
За описание какой бы задачи автор ни брался, почти всегда повествование приходит к тому, что «нормально это не сделать». Что уж говорить, если в книге есть целый раздел «Проблемы распределенных систем». Читая всё это, понимаешь, что гарантии – это слово, которое приходится использовать с оговорками, когда речь идёт про распределенные системы. Даже читая главы про транзакции, консистентность, репликацию, которые ассоциируются у людей с надежностью, автор то и дело подкидывает хитрые сценарии, при которых всё ломается. Вашей реальностью становятся бесконечные компромиссы. Многие из них необратимы и постепенно лишают вас пространства для маневра, что особенно неприятно в условиях постоянно меняющихся бизнес-требований.
Не научит создавать реальные системы
В те редкие моменты, когда автор перестаёт вгонять вас в депрессию от тщетности распределённого мира, он всё равно не даёт готовых рецептов. В книге нет чётких критериев, как выбирать подход к моделированию данных, настраивать шардирование или запускать MapReduce или потоковую обработку данных. Книга описывает эти концепции достаточно высокоуровнево, чтобы было достаточно для общего понимания механики, но информации всё равно недостаточно, чтобы пойти и применить эти знания. Максимум упоминаются инструменты, которые что-то нужное умеют делать. Иногда, проблемы тех или иных решений просто вскользь перечисляются, без каких либо подсказок к их решению. В общем, стать, например, разработчиком баз данных с её помощью у вас не получится.
Не поможет подготовиться к System Design Interview
Я часто слышал, что эту книгу рекомендуют для подготовки к этому испытанию. Проблема в том, что это настолько специальное мероприятие, нацеленное на демонстрацию опыта, что подобные обзорные книги тут совсем не помогают. Опытный интервьюер быстро закопается в детали вашей реализации. В этот момент широкий кругозор, который дает книга, вам уже не поможет.
Книга говорит: «Вот 15 способов сделать репликацию, и у каждого свои фатальные недостатки». Интервьювер: «У нас 100к RPS, нарисуй схему с балансировщиком и кешем за 40 минут». Книга учит сомневаться, а интервью требует демонстрировать уверенное решение. Если вам нужны реальные советы по подготовке – они в моей статье на Хабре.
Зачем же её читать
При всех этих недостатках, эта книга даёт две бесценные вещи.
Первая – язык и понятийный аппарат. Вы начнете понимать, о чём говорят сеньоры, когда обсуждают «согласованность в конечном счёте» или «векторные часы». Например, после прочтения второго издания я наконец понял для себя разницу между linearizability и serializability – а это больная тема на стыке CAP и ACID.
Вторая важная вещь книги – прививка от наивности. Без неё многие лезут в распределённые системы с верой в идеальный мир. Так что читать её надо, но с правильными ожиданиями.
Ещё до этой книги я много читал про «гарантии» баз данных, видел эпичные инциденты в индустрии, и решал реальные задачи в распределенных хранилищах. Теперь я могу сказать уверенно: работая с распределёнными системами, забудьте, что с ними всё когда-нибудь будет «зашибись». Они подобны сиренам: испортили жизнь многим отважным людям. Бывает, что без них задачи бизнеса не решаются, и тогда знания из книг, похожих на эту, таки позволяют пройтись по лезвию бритвы. Но если вам дорога ваша психика, то связываться с ними, без сильных на то оснований, не стоит.
Именно поэтому я вижу тут парадокс: книга о распределенных системах обработки данных как минимум удерживает вас от их необоснованного создания, а как максимум – от наивного использования. И, возможно, это её главная ценность.