Bassem Dghaidi: «Simple is complicated enough» — system design без театра овер-инженерии (Рубрика #Architecture)

Почти любой разговор о разработке сейчас довольно быстро съезжает к моделям, агентам и процентам сгенерированного кода. Поэтому эта 46-минутная беседа на Beyond Coding особенно хороша: AI появляется только в последней четверти. До него — спокойный инженерный разговор о system design, вертикальном масштабировании, цене абстракций и ответственности перед бизнесом. Очень уместный контрапункт общему AI-хайпу.

В гостях у Patrick Akil — Bassem Dghaidi, senior software engineer в GitHub, работающий над GitHub Actions. У него больше 15 лет опыта в разных доменах: от банков и контейнерных терминалов до интернет-сервисов. В разговоре он опирается на конкретные задачи — перестройку частей GitHub Actions, инфраструктуру терминала и системы для банков, — поэтому «масштаб» здесь не упражнение у доски.

Основной тезис Dghaidi: system design — не конкурс на самое большое количество модных коробочек. Систему стоит проектировать на следующий порядок величины, а не на воображаемые 100x, и только после того, как данные показали предел текущего решения. ПО не строят один раз — оно постоянно развивается, поэтому архитектура требует регулярных инвестиций, а не одной попытки угадать устройство системы на десять лет вперёд.

Из разговора я бы забрал четыре мысли.

1️⃣ Масштабирование начинается с измерений По словам Dghaidi, некоторые сервисы GitHub обрабатывают миллионы запросов в секунду всего на пяти-шести контейнерах. Это внутренний пример спикера, не независимый бенчмарк. Сам контекст перестройки позже описал GitHub: старое ядро Actions обслуживало 23 млн jobs в день, новую архитектуру проектировали с запасом 10x, а к декабрю 2025 года она держала 71 млн jobs в день. Принцип тот же: сначала реальная кривая нагрузки, потом распределённая сложность.

2️⃣ Конкретное решение полезнее универсального фреймворка Кеш, NoSQL или новая абстракция появляются, когда есть конкретное узкое место. Иначе невозможно осмысленно выбрать компромиссы: универсальная конструкция оптимизируется сразу для всех гипотетических задач — и ни для одной реальной.

3️⃣ Архитектуру надо объяснять в единицах, что понятны бизнесу На контейнерном терминале, который вспоминает Dghaidi, задержка означала деньги и иногда риск для людей, а не просто красный график времени ответа. Его совет инженерам: переводить «база данных перегружена» в стоимость простоя, окно разгрузки, скорость поставки фичи и риск для клиента. Самый красивый Kubernetes-кластер ничего не доказывает, пока не показан измеримый эффект для бизнеса.

4️⃣ AI меняет рычаг, но не задачу инженера Dghaidi утверждает, что агенты пишут около 90% его кода. В одном кейсе агент за 20 минут собрал и прогнал три бенчмарка для разных ключей Redis — вручную это, по его оценке, заняло бы два-три дня. Освободившееся внимание он тратит на паттерны доступа к данным, надёжность, эксплуатацию и последствия ошибки. Его аналогия с автоматическим сцеплением на мотоцикле здесь точная: переключать передачи стало проще, но дорогу, скорость и допустимый риск всё ещё выбирает человек.

Есть и с чем поспорить. Dghaidi прямо называет увольнения дегуманизирующим, но эффективным способом перераспределять инженерные ресурсы. Для меня это звучит слишком бухгалтерски. Но от этого запись только честнее: собеседники обсуждают реальные компромиссы, а не продают ещё одну серебряную пулю.

В эпоху, когда заголовки соревнуются в том, какая модель написала больше кода, здесь задают менее эффектные вопросы: какой предел мы измерили, какой риск уменьшаем, кто будет эксплуатировать решение и что изменится для бизнеса. AI из разговора не исчезает — он просто возвращается на своё место: мощный инструмент внутри инженерной системы, а не замена system design.

#Architecture #SystemDesign #Engineering #Software #AI #AI4SDLC