Меня попросили прочитать часовую лекцию про системный дизайн и сделать так, чтобы после неё людям захотелось пойти учиться дальше.

И вот тут я задумался.

Потому что системный дизайн — это огромная область знаний. Базы данных, распределённые системы, отказоустойчивость, производительность, архитектурные паттерны и ещё огромное количество тем. За час рассказать это невозможно.

Сначала у меня появилась идея рассказать про то, что большие прорывы происходят тогда, когда люди нарушают правила.

Но чем больше я об этом думал, тем больше понимал, что это не совсем так.

Проблема не в том, чтобы нарушать правила.

Проблема в том, чтобы понимать, почему эти правила вообще появились.

Хороший инженер знает правила.

Сильный инженер понимает причины появления правил.

А великий инженер умеет отличать законы природы от исторических компромиссов.

Большинство правил вокруг нас появились не потому, что они идеальны. Они появились потому, что когда-то давно кто-то решал конкретную задачу в конкретных условиях.

Проходят годы.

Технологии меняются.

Ограничения исчезают.

А правила остаются.

Именно в этот момент появляется возможность сделать шаг вперёд.

Когда я учился на факультете вычислительной математики и кибернетики, меня очень раздражало количество математики в программе. В дипломе у меня что-то около 16 различных математических дисциплин, а программирования, как мне тогда казалось, было преступно мало.

Особенно раздражал математический анализ.

Но спустя много лет я понял одну интересную вещь.

На некоторых экзаменах нам давали задачу примерно такого вида:

Есть набор аксиом.

Из него убирается одна аксиома.

А дальше нужно понять, останется ли верным утверждение, которое находится где-то далеко в теории.

Чтобы ответить на этот вопрос, недостаточно было помнить конкретную формулу или конкретную теорему.

Нужно было понимать всю цепочку причинно-следственных связей.

Понимать, почему эта теорема вообще работает.

На чём она стоит.

Какие зависимости её поддерживают.

Именно тогда становится видно, какие вещи являются фундаментальными, а какие — всего лишь следствием ранее принятых допущений.

Мне кажется, в инженерии происходит ровно то же самое.

Большинство конкурентных преимуществ рождается не из знания ответов.

Они рождаются из понимания причин.

Из способности задавать вопрос:

"А почему вообще считается, что нужно делать именно так?"

Например, много лет назад большинство систем анализа сетевого трафика строились вокруг специализированного оборудования. Это считалось единственно правильным подходом.

Но в какой-то момент стало понятно, что производительность стандартных серверов, шин PCI и сетевых адаптеров выросла настолько, что некоторые старые ограничения больше не существуют.

Правило осталось.

Причина его появления исчезла.

Именно такие моменты обычно и становятся точками рождения новых продуктов и новых рынков.

Наверное, если бы меня попросили объяснить, зачем изучать системный дизайн, я бы ответил так.

Не для того, чтобы знать больше паттернов.

И даже не для того, чтобы строить правильные системы.

А для того, чтобы понимать причины, по которым эти системы устроены именно так.

Потому что именно там обычно и прячутся самые интересные возможности.