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
YouTube
Why The Best Software Engineers Focus On System Design
System design interviews often focus on theoretical complexity, but how do Senior Engineers at GitHub actually approach scaling? In this episode, Bassem Dghaidi breaks down how to think about system design when real business impact is on the line.
We discuss…
11
6
3August 27, 2026 2.4K 6 38
