Пока этот черновой набросок сделан по горячим следам ознакомления с первыми несколькими главами книги “System Design Interview” за авторством Alex Xu. До данного момента я детально не изучал текущую ситуацию в этой области, но эта книга настолько прочно обосновалась в бестселлерах Амазона, что любопытство начало брать верх.
Автор представлен как опытный инженер и предприниматель, который работал в Twitter, Apple, Zynga и Oracle. При этом, в Oracle и Apple он работал 6 и 3 месяца соответственно. Видимо, что-то пошло не так. Да и в остальных компаниях он был в статусе рядового инженера. Но это совершенно не исключает того факта, что он может быть опытным специалистом для подготовки к интервью в подобных организациях. Меня больше всего настораживает, какие именно стандарты системного дизайна эти компании начинают диктовать рынку. И не проигрывают ли от этого все и они в том числе?
Первый важный аспект прячется в истории. Подобные крупные корпорации, как правило, создали свои ключевые продукты сравнительно давно. И на первых своих шагах они не отличались выдающимся дизайном и архитектурой. Прошли годы эволюции и совершенствования при практически не ограниченных бюджетах. И вот, в некоторой точке этого процесса, на достаточно высокому уровне зрелости, оказываются подобные специалисты, которые действуют через призму текущего состояния. И за сценой оказывается удручающая картина, какое количество ошибок, просчётов и упущений было сделано в процессе эволюции и как на них бы мог повлиять и предотвратить системный дизайн.
Перед большинством предпринимателей и стартапов будет стоять совершенно другая задача. Нужно в рамках очень ограниченного бюджета и времени создать продукт, который будет конкурировать с тем, что уже не первый год на рынке и при этом надо обеспечить ему высокую масштабируемости. Как функциональной, так и нагрузочной. Речь идёт о популярном в современном мире MVP.
Каким образом можно сделать с одной стороны очень простой продукт, а с другой - обеспечить ему высокую масштабируемость? Обеспечить правильные интерфейсы между компонентами системы, чтобы в дальнейшем можно было их заменить на более сложные, но при этом не менять эти самые интерфейсы. Простой пример - это USB-интерфейс. Он позволяет подключать к компьютеру различные устройства, сейчас это может быть флешка на 16GB, а завтра - внешний жёсткий диск на 16TB. Программа, которая работала с этим диском останется неизменна. Таким образом на этапе дизайна наша задачать обобщать и упрощать. Урощение здесь означает не примитивизацию, а более экономичные реализации, которых нам может быть достаточно на первых этапах. И мы знаем, что в любой момент можем их заменить на более сложные. Закрывая по мере развития наиболее слабые места.
Но автор сразу начинает интервью с вопроса, какой клиент будет использоваться, мобильный или веб? А почему он не спросил про смарт-часы? А про VR-гарнитуры? Что произойдёт, если мы захотим сделать приложение для TV? Для системного дизайна существует клиент, который в своей реализации может быть очень специфичен. Но мы знаем, что с нашей системой он общается по некоторому интерфейсу. А значит, здесь и сейчас мы можем сделать самый простой, которого будет достаточно для проверки бизнес-гипотезы и работоспособности всей системы в целом.
Дальнейшее интервью также входит в конфликт с принципами дизайна в целом. Какие бы подходы мы не взяли, SOLID или DDD, везде будет стремление к выделению правильных абстракций, правильных доменов и в данном случае мы бы говорили о правильных ролях. Есть, скажем, роль “Requirement Manager”. Этот человек постарается сформировать правильный словарь предметной области, пользовательские роли, процессы и в идеале мы должны получить набор “executable specifications”. Системный дизайн, по крайней мере в той его части, которая демонстрируется в книге, отвечает за совершенно другие, холистические факторы. Он должен стараться игнорировать несущественные детали. Ни один уважающий себя архитектор не задаст вопрос “в каком порядке будут сортироваться новости”.
На вопросы про планируемую нагрузку вроде “How many friends can a user have?” и “What is the traffic volume?” ожидать качественного ответа от заказчика нельзя. Он обманет. Последний раз когда, когда мне ответили, что больше 10М транзакий в целом не ожидается, я за год более чем на 10М в месяц. В идеале стоит всегда тренировать себя мыслить в терминах “бесконечности”. Но понятно, что есть внутренние решения или специализированные рынки, где правят бал совершенно другие критерии.