По мотивам беседы с Bassem Dghaidi (Senior Software Engineer, GitHub)
В профессиональной разработке программного обеспечения нет места "хобби-подходу". Бизнесу важны не красивые слова, а конкретные числа, реальные метрики и ощутимый эффект. И одна из областей, где этот разрыв между теорией и практикой особенно заметен - это системный дизайн.
Парадокс, но каждый разработчик знает модные слова вроде Kubernetes, шардинг, кластеризация, distributed consensus, но когда дело доходит до реальных продуктов, 90% команд копируют архитектуру крупного Big Tech, даже если их масштабы несопоставимы.
В разговоре с подкаста Beyond Coding старший инженер GitHub - Баcсем Дгайди (Bassem Dghaidi) объяснил, почему это разрушает стартапы, какие ошибки совершают инженеры и как в GitHub принимают системные решения, опираясь на реальные данные.
1. Самая частая ошибка: архитектура ради статуса
Одна история из подкаста идеально иллюстрирует проблему.
Стартап решил мигрировать на Kubernetes как у больших компаниях по причинам:
инженеры хотят опыт с Kubernetes
так будет быстрее и масштабируемее
cloud-native - это же наше всё
На практике всё закончилось:
гигантским AWS-счётом,
медленными релизами,
падением скорости разработки,
остановкой фичей,
выделением отдельной команды только на то, чтобы "починить инфраструктуру".
И всё это без единой реальной причины.
Главная мысль Бассема:
Большинство хочет не решать проблемы, а владеть "классной" архитектурой.
2. Миф о раннем масштабировании: никто не знает "когда пора"
В теории существует множество статей и схем:
Если у вас X RPS(Requests Per Second) - делайте горизонтальное масштабирование
Если база растёт до N GB - пора шардировать
Но всё это не правила, а умозрительные конструкции.
В реальности "правильный момент" вообще не очевиден.
Баccем приводит пример из GitHub:
"Мы запускали сервисы с миллионами запросов в секунду на 5–6 контейнерах в небольшом Kubernetes-кластере".
Да, GitHub это огромный проект. Но его части работают на удивительно простых архитекурах и пока не упёрлись в потолок ничего не меняли.
3. Horizontal vs vertical scaling: вертикаль - не менее мощный инструмент
Мы привыкли думать:
вертикальное масштабирование - "для новичков"
горизонтальное - "для профессионалов"
Но это миф. Современные облака дают машины с 120 CPU и терабайтами RAM.
И одна такая машина может прожить очень долго, прежде чем понадобится сложность с распределёнными системами.
Вместо того чтобы строить тему Kafka + shards + distributed locks, зачастую достаточно:
один VM
нормальная оптимизация запросов
репликация базы (master → replica)
небольшой кэш
И всё - система выдерживает тысячи и даже миллионы запросов.
4. Как в GitHub принимают архитектурные решения
GitHub не строит "идеальную систему будущего".
Они делают иначе:
Максимально используют текущую архитектуру.
Смотрят реальные графики загрузки, а не воображаемые.
Моделируют рост на 3–5 лет вперёд, опираясь на данные.
Переписывают только тогда, когда:
существующая архитектура физически перестаёт выдерживать,
улучшения уже невозможны.
Так переписывали части GitHub Actions не из-за моды, и не из-за желания попробовать Go, Rust или "микросервисы", а потому что реальная нагрузка достигла предела.
5. Ты - стартап? Тогда забудь о распределённых системах
Баccем говорит максимально конкретно:
"Будь я CTO стартапа — я бы запускал всё на одном VM".
И объясняет почему:
пока у вас 100–1000 пользователей, нет смысла в 100х-масштабировании;
горизонтальное масштабирование не бесплатно — оно увеличивает стоимость поддержки;
сложные системы умирают, когда количество инженеров уменьшается;
ранняя сложность убивает скорость разработки.
6. Почему простые архитектуры побеждают
Вот список того, что дорого:
распределённые транзакции
консистентность между множеством сервисов
отказоустойчивость на уровне нескольких регионов
шардинг
сложная инфраструктура
оркестрация
Вот что дешево:
один сервис
одна база
простые CRON-задачи
кэширование
репликация
Чем меньше движущихся частей, тем быстрее разрабатывается, проще поддерживается,
меньше инцидентов, ниже счёт в AWS, легче адаптировать новых инженеров, проще переписать при необходимости.
7. Почему интервью по системному дизайну искажает реальность
Баccем поднимает важную тему: многие компании копируют стиль интервью Big Tech, но сами не работают на таком масштабе.
GitHub спрашивает о распределённых системах не из моды, а потому, что там это нужно каждый день.
Но обычные компании:
нанимают инженеров «на всякий случай»,
ожидают от них навыков, которые они никогда не применят,
а потом получают слишком сложные системы.
8. Системы должны эволюционировать - это нормально
Когда-то ПО строили на 20–30 лет вперёд.
Но сегодня это невозможно потому что:
технологии меняются быстрее,
требования бизнеса меняются,
трафик растёт неравномерно,
люди в командах меняются каждые 2–3 года,
сервисы переписываются и перезапускаются.
Лучше всего строить систему под ближайший уровень нагрузки. Когда его достигаете переходите к следующему уровню. И повторяйте этот процесс по мере роста.
9. Заключение - простота как конкурентное преимущество
Системный дизайн это не про:
микроcервисы ради микросервисов
Kubernetes ради галочки
архитектуру "как у Netflix"
модные слова
Это про:
реальные данные
реальные нагрузки
реальные бизнес-кейсы
реальные ограничения команды
реальную стоимость ошибок
Главное правило:
Строй простую систему.
Упирайся в её пределы.
Потом усложняй - но только когда это нужно.
Эта философия работает в GitHub при миллионах запросов в секунду.И она тем более работает в стартапах и небольших продуктах.