The Man Who Revolutionized Computer Science With Math (Рубрика #DistributedSystems)

В этом видео Лэсли Лэмпорт за 8 минут рассказывает про специальную теорию относительности, причинность и распределённые системы, а также как это все свзяано между собой. Это видео - короткое интервью Quanta Magazine где он объясняет смысл своей классической фразы

Вы понимаете, что пользуетесь распределенной системой, когда поломка компьютера, о существовании которого вы даже не подозревали, приводит к останову всей системы, а для вас - к невозможности выполнить свою работу

Но лучше сначала расскзать, а чем известен Лэсли Лампорт, который получил премию Алана Тьюринга (аналог Нобелевской, но в информатике). За ним числятся
- Lamport clocks + happens‑before: как упорядочивать события без «общих часов»
- Paxos и replicated state machine: фундамент отказоустойчивых кластеров/хранилищ
- LaTeX: де‑факто стандарт научной вёрстки
- TLA+: спецификации + model checking, чтобы ловить дизайн‑баги до кода

Самое вкусное в этом интервью - это рассказ про связь специальной теории относительности из физики и теории распределенных систем из информатики. Мне как учившемуся на Физтехе очень понравилась эта часть про мультидисциплинарность и пользу физики (хотя я учился на факультете прикладной математики, но физика у нас выдавалась всем так, чтобы никто не ушел обиженным от того, что ее недополучил). Так вот, в СТО (специальной теории относительности) нет универсального "сейчас": наблюдатели могут спорить, что было раньше. Но они не спорят о причинности - событие A может повлиять на B только если сигнал (не быстрее света) мог дойти от A до B. И Лэсли Лэмпорт перенес это 1‑в‑1 в распределённые системы:
- Нет глобального времени (латентности, дрейф, партиции)
- Зато есть причинный частичный порядок: "могла ли информация из A повлиять на B"
В итоге, в распределёнке важнее порядок, совместимый с причинностью, чем "точные таймстемпы". Отсюда появились логические часы, тотальный порядок поверх частичного и согласованная эмуляция одной последовательной state machine несколькими узлами. В общем, я раньше не знал как Лэсли к этому всему пришел, а тут узнал и понял, что действительно это блестящая игра разума.

Но если возвращаться на грешную землю, то можно почерпнуть такие инсайты для инженеров и технических руководителей
- Programming ≠ coding. Код - последняя миля. До него должны появиться модель поведения и явные допущения (сеть, сбои, порядок сообщений, часы).
- "Алгоритм без доказательства - гипотеза". Даже если вы не пишете формальные доказательства, TLA+/модель‑чекер часто ловят те баги, которые тестами почти не поймать.
- Ищите причинность. Когда спорите о порядке операций в БД/кэше/очереди - спрашивайте не "который час был раньше", а "какая информация могла попасть куда".

Ну и отдельный момент про любимый алгоритм Лэсли "Bakery (mutual exclusion)". Здесь метафора пекарни работает так: каждый процесс берёт «номерок», и в критическую секцию входит минимальный (при равенстве - по id). В оригинальной работе он даже отмечает, что такие "номерки" можно реализовать распределённо: хранить у владельца процесса и читать по сети.
Красота в том, что алгоритм корректен даже при очень слабых предположениях о памяти: чтение, пересекающееся с записью, может вернуть произвольный "мусор", а докатазательство всё равно работает. Лэмпорт понял это, когда дописывал доказательство - это отличный аргумент, зачем вообще писать спецификации/доказательства: они находят свойства, которых вы "не закладывали".

#DistributedSystems #Software #Engineering #Architecture #Leadership #SystemDesign

История Linux и UNIX! Кто породил ВСЕ современные системы! (Рубрика #Engineering)

Интересное видео про историю операционных систем от канала PRO Hi‑Tech, из которого хорошо видно, что в истории unix или gnu linux победила не "одна фича", а сочетание идей + институтов (люди, лицензии, стандарты, сообщества). Из таймлана развития событий видно, что многие технологии приняли участие в ходе этой истории
- 1969: Unix в Bell Labs - простые абстракции под жёсткие ограничения (знаменитые пайпы и простые инструменты, что ждут на вход текст и )
- 1973: переписывание на C → переносимость как стратегия (переносимость между разным железом)
- 1984: BSD + TCP/IP → Unix становится “родным” для сетей
- 1988: POSIX → общий контракт совместимости среди зоопарка Unix
- 1991: Linux (ядро) → недостающий пазл для свободной системы (ядро экосистемы GNU)
- 1993+: Debian/*BSD → управление качеством, релизами, пакетами
- 2000–2008: Darwin/macOS и Android → Unix‑подход уходит в массовые платформы (на Android и в основу Mac)

Из всей этой истории можно сделать определенные выводы, что полезны и в продуктовой разработке
- Переносимость = драйвер экосистемы. Инвестируйте в стабильные API/ABI и “тонкий слой” платформенной специфики
- "Файл/процесс/pipe" → сила простых контрактов. Малые утилиты и композиция = предок современных микросервисов и пайплайнов
- Фрагментация лечится стандартами. POSIX появился не из любви к бюрократии, а чтобы снизить стоимость переносимости
- Open‑source ≠ анархия. Сообщества выживают за счёт governance, CI, правил релизов и ответственности за интеграцию
- Лицензия - архитектурное решение. Она определяет, кто и как может вкладываться, монетизировать и форкать
- "Ядро" ≠ "продукт". Дистрибуция/SDK/пакеты/политики поставки часто важнее самого kernel

Для технических лидеров это можно приземлить на набор полезных по моему мнению советов
- Зафиксируйте "поверхность контрактов": публичные API/CLI/форматы, SLA, обратная совместимость
- Постройте конвейер принятия вкладов: code review → CI → релизные ветки → rollback
- Разделяйте владельцев: ядро/платформа vs userland vs дистрибуция/поставка
- Не верьте красивым нарративам на слово: проверяйте даты/причины решений - история любит упрощения (посмотрите оригинальный фильм и почитайте доки - составьте свое мнение)

Более подробный разбор есть на моем сайте system-design.space.

#Engineering #Documentary #Architecture #Software #DistributedSystems #Leadership

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)

Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space

Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру

Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.

Встречаемся завтра c кофе ☕️ в 11:00 на YouTube

#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)

На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие
​
- Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию"
​- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования
- Разобрали типовые ошибки кандидатов​
- - Сразу рисовать «кубики и стрелочки» без уточнения ограничений,
- - Оптимизировать за пределами реальных bottleneck’ов
- - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.)
​- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры
​- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии
​- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями
​- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения.
​
Если говорить про инсайты для руководителей, которыми можно поделиться, то
- Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно
​Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника.
​- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах).
​- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги.
​
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

The Rise and Rise of FastAPI (Рубрика #API)

Интересная мини‑документалка о FastAPI, которая длится меньше 10 минут. В ней говорится о том, как FastAPI прошел путь сверхбыстрого роста open source проекта по траектории вида: side‑project → "индустриальный дефолт" для API на Python. После документалки мне стало интересна судьба этого проекта и кажется, что FastAPI "выстрелил" не потому что "он fast", а потому что собрал в одном месте:
- Стандарты** (ASGI, OpenAPI/JSON Schema)
- Типизацию как интерфейс** (type hints → Pydantic модели)
- DevEx как продукт (авто‑документация, предсказуемые ошибки, быстрый старт)
- Композиционную архитектуру (Starlette‑стек, middleware, зависимости)
В итоге, для команд, что его используют результаты выглядят так, что у них меньше боли на границах ответственности (APE endpoints) + быстрее интеграции + быстрее онбординг

Если говорить про вехи развития проекта, то получится следующее
1️⃣ Side‑project → фреймворк
Фокус был на создании "API без боли": валидируй вход, сериализуй выход, документируй автоматически

2️⃣ Технический стержень
- ASGI‑модель (современная I/O‑архитектура)
- Starlette как "тонкий" веб‑слой
- Pydantic как слой данных: строгая валидация/сериализация поверх type hints

3️⃣ Контракт становится "живым артефактом"
- OpenAPI генерится из кода.
- Интерактивная документация /docs и /redoc делает API‑контракт частью ежедневной разработки, ревью и интеграций

4️⃣ Снежный ком крутого DevEx (developer experience)
- Шаблоны, практики, интеграции, “как правильно” из коробки.
- Порог входа падает → adoption растёт.

5️⃣ Взросление и коммерциализация вокруг поддержки
- Когда популярность становится инфраструктурой для бизнеса, неизбежно появляются: поддержка, консалтинг, managed‑подходы, облака и т.п.
- Это меняет ожидания: "фреймворк" → "платформа вокруг фреймворка".

Если раскрывать ключевые инсайты подробнее, то получаем примерно так
1) FastAPI - это "композиция стандартов + DX", а не "магия"
FastAPI не "заменяет архитектуру". Он фиксирует удачный дефолт: типы → модели → валидация/сериализация → схема → документация.
По итогу у нас становится меньше неявных договорённостей и "случайных JSON"

2) Контракт‑ориентированная разработка - становится нормой
OpenAPI в FastAPI - не "дока на потом", а контракт в процессе:
- Проще подключать фронт
- Проще делать партнёрские интеграции
- Проще ревьюить изменения
В итоге, скорость и надежность на другом уровне

3) Производительность - следствие правильной I/O‑модели, а не цель
ASGI + async дают выигрыш только если вы:
- Не блокируете event loop
- Используете правильные драйверы/клиенты
- Умеете проводить границы sync/async
Правда, "async ради async" = быстрый путь к деградации и непредсказуемым p95/p99

4) OSS‑рост почти всегда приводит к вопросу устойчивости
Если фреймворк становится критическим для тысяч компаний, возникает давление:
- На поддержку
- На эксплуатационные "best practices"
- На продуктовую упаковку вокруг деплоя/наблюдаемости
В итоге, с точки зрения технического руководителя это уже не просто "выбор библиотеки", а уже управление зависимостью

На сайте system-design.space есть чуть более подробный разбор.

#Engineering #Architecture #DistributedSystems #Software #SoftwareArchitecture

Граф знаний сайта system-design.space (Рубрика #SystemDesign)

Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи.

Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ
- Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются
- Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу
- Скролл / pinch позволяыт зумить. При приближении появляются названия глав
- Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить
- Цвета узлов соответствуют своим темам (кластерам)
- По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные
- Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии.

Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить).

#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

[1/2] How AWS S3 is built (Рубрика #Architecture)

Интересный выпуск подкаста "The Pragmatic Engineer", в котором Gergely Orosz общается с Mai‑Lan Tomsen Bukovec, VP of Data & Analytics в AWS, которая руководит развитием/эксплуатацией S3. А Simple Storage Service - это одна из самых масштабных систем в мире, поэтому из этого обсуждения можно извлечь много интересного

1️⃣ Масштаб, который ломает интуицию
В S3 сотни миллионов транзакций в секунду, 500+ трлн объектов, сотни эксабайт данных. Интересно, что Gergely и Mai‑Lan говорят о том, что сложенные в стопку десятки миллионов дисков в S3 почти смогут достать до МКС

2️⃣ Переход к strong consistency - как крутая инженерная миграция
S3 стартовал с eventual consistency (2006), но затем перешёл к strong consistency без ухудшения доступности и без удорожания для клиентов. Архитектура была примерно такой: replicated journal + протокол когерентности кеша с идеей failure allowance

3️⃣ Тихий переход на Rust в критическом request path
Команда переписала почти всё performance‑critical в обработке запросов на Rust, с мотивацией: максимум perf и минимум latency

4️⃣ 11 девяток durability - это "измерение факта", а не обещания
Durability уровня 99.999999999% поддерживается не магией, а флотом фоновых сервисов: микросервисы аудита, которые непрерывно проверяют каждый байт, и отдельные repair‑механизмы, которые автоматически чинят.

5️⃣ Формальные методы - это production‑практика, а не академические изыски
В S3 активно используют формальные методы верификации: при изменениях в подсистеме индексов/консистентности запускаются автоматические формальные проверки, чтобы не было регресса модели. И это не просто слова: в публикации Amazon Science про "lightweight formal methods" описан опыт, где такие методы помогли не пустить в прод 16 проблем

6️⃣ Главный враг сегодня - correlated failures
Одиночные поломки нормальны, но опасны коррелированные отказы: общий rack/AZ/питание/и т.п. Архитектура строится вокруг борьбы с этими корреляциями: репликация по AZ, quorum‑подходы, физическая/логическая декорреляция, хранение копий в разных fault domain

7️⃣ Сотни микросервисов - и многие из них не про трафик
В эпизоде фигурирует порядок 200+ сервисов, и заметная часть из них занимается health checks / audit / repair, а не пользовательскими запросами. Сложность удерживается через упрощение - каждый сервис должен быть максимально сфокусирован

8️⃣ S3 перестаёт оперировать только бакетами: новые примитивы Tables и Vectors
Появились новые примитивы
- S3 Tables: объектное хранилище с встроенной Apache Iceberg‑поддержкой и фоновой оптимизацией таблиц (перепаковка/компакшн и т.п. "в фоне"). AWS заявляет до 10x TPS vs Iceberg‑таблицы в обычных S3‑бакетах
- S3 Vectors: нативное хранение/поиск векторов в S3. В эпизоде - инженерная идея vector neighborhoods (предрасчёт кластеров оффлайн), чтобы получить тёплые запросы <100ms, и очень большие масштабы индексов/бакетов

9️⃣ Crash consistency - как мировоззрение
Настоящие инженеры мыслят так: система должна возвращаться в корректное состояние после fail‑stop; проектирование идёт через перебор возможных состояний при отказах + набор сервисов, которые удерживают инварианты

🔟 Принцип Scale must be to your advantage
Нельзя строить так, чтобы рост сервиса ухудшал характеристики; на масштабе, наоборот, должны появляться эффекты, улучшающие надёжность (например, декорреляция нагрузок)

В продолжении расскажу как можно этот опыт переложить на практические рекомендации инженерам и техническим руководителям.

#Culture #Management #Leadership #Processes #Engineering #Software #Architecture #DistributedSystems #SystemDesign

[2/2] How AWS S3 is built (Рубрика #Architecture)

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

Для инженеров можно забрать идеи о том, что
- Надёжность - это не try/catch и ретраи, а отдельные системы: аудит, восстановление, непрерывная проверка инвариантов. Если у вас данные с высокими ставками, то думайте не только про happy path, но и про способы самовосстановления
- Корреляция отказов важнее единичных сбоев - дизайн по fault domains (rack/AZ/region), хаос‑тесты не для того, чтобы случайно вырубить ноду, а для того, чтобы отключить общий домен отказа
- Rust в критическом пути - это хороший способ оптимизации, если вы пишете сетевой/IO‑интенсивный runtime или любой hot path - memory‑safe системный язык становится конкурентным преимуществом
- Формальные методы могут быть не избыточно тяжелыми, а практичными: не обязательно верифицировать всё. Достаточно выбрать 1–2 инварианта (консистентность, crash safety, права доступа) и поставить автоматическую проверку рядом с CI

А для технических руководителей это история про то, что
- Сложность можно победить ограничениями - сервисов может быть сотни, но каждый должен быть простым и сфокусированным, а иначе система станет неуправляемой.
- Метрики уровня SLO должны быть измеряемыми, а не декларативными: идея мы можем ответить, какая у нас фактическая durability за неделю/месяц - это про культуру инженерии, где операционка встроена в дизайн.
- Correctness как продукт - automated reasoning/формальные проверки как инвестиция, которая позволяет двигаться быстро и не ломать. Это особенно важно там, где тестами невозможно покрыть комбинации состояний
- Хранилище S3 превращается в data‑платформу: Tables/Vectors - это намёк, что часть базы/поиска/оптимизации всё чаще будет жить рядом с storage. Для архитектуры это означает: регулярно пересматривайте, что выгоднее - строить самим или сдвигать вниз в managed‑примитивы.

Если хочется попробовать этот подход у себя, то можно
- Нарисовать fault domains (реальные) и проверить, где у вас скрытая корреляция.
- Добавить сервис аудита хотя бы для ключевых инвариантов (checksums/версионирование/сверка индексов/реплик).
- Выделить 1 критичный модуль и использовать легковесный формальный подход: спецификация + автоматическая проверка (пусть даже минимальная).
- Пересмотреть сервисы на предмет перегрузки функциональностью и разложить ответственность так, чтобы каждый компонент был тупым, маленьким и проверяемым.

#Culture #Management #Leadership #Processes #Engineering #Software #Architecture #DistributedSystems #SystemDesign

An Illustrated Guide to AI Agents (Рубрика #Agents)

Пока летел обратно из Лондона в Москву успел прочитать эту книгу и могу ее рекомендовать всем. Ее пишут Jay Alammar и Maarten Grootendorst - авторы крутой книги "Hands-On Large Language Models", о которой я уже рассказывал. Новая книга про агентов настолько же хороша, как предыдущая, а еще она находится в процессе написания и пока написана только половина глав. Уже видно, что новая книга продолжает тему LLM, но уже в мире AI agents - то есть в первой книге читатели могут увидеть как устроены LLM (там почти 300 иллюстраций), а в новой - как из LLM собирать агентские системы. То есть первая книга отвечает на вопрос "что у модели внутри", а новая - как вокруг модели построить память, tools, планирование и координацию. В общем, рекомендую читать именно в таком порядке, чтобы сначала понять движок, а потом - архитектуру приложения.

Если говорить про готовность книги, то сейчас уже готовы основные главы

1. Introduction - зачем вообще нужен "agent", чем он отличается от просто LLM-вызова, где кончается чат-бот и начинается система. Это глава для выравнивания терминов и общей архитектурной картинки.
2. Reasoning LLMs - что меняется, когда модель умеет не только отвечать, но и проходить цепочки рассуждений / test-time reasoning. Это важная глава, чтобы не путать "умный ответ" и "умение модели размышлять".
3. Memory - это одна из самых практичных частей: контекст, short-term vs long-term memory, context engineering, как агент "помнит" и почему память быстро становится архитектурной, а не только ML-задачей.
4. Tool Usage, Learning, and Protocols - эта глава про инструменты, function calling, интеграции и протоколы вроде MCP. То есть про момент, когда LLM перестает быть только генератором текста и начинает что-то делать во внешнем мире.
5. Planning and Reflection - здесь речь про декомпозицию задачи, пересборку плана, self-critique и feedback loops. Это уже территория, где агентность начинает влиять на надежность и стоимость решения.
6. Multi-Agent Systems - когда одного агента мало, как делить роли между несколькими, а также как выстроить координацию агентов. Тут появляется и A2A протокол (раньше я уже как-то рассказывал про MCP vs A2A протокол)

В общем, мне книга зашла и я буду следать за появлением новых глав. Думаю, что она будет полезна инженерам и техлидам, которым нужно не увидеть "еще одно демо", а построить себе в голове ментальную модель: из каких блоков вообще собираются AI agents и где в этой конструкции живут реальные инженерные риски. И если "Hands-On Large Language Models" был хорошим входом в тему LLM, то "An Illustrated Guide to AI Agents" выглядит как хороший вход в тему агентских архитектур и мульти-агентных систем

P.S.
Более подробный разбор есть на сайте system-design.space.

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems

The third golden age of software engineering - thanks to AI, with Grady Booch (Рубрика #AI)

Интересное интервью Гради Буча, создателя UML и Chief Scientist for Software Engineering в IBM, в подкасте The Pragmatic Engineer. Гради и Gergely Orosz, автор подкаста, обсуждают как меняется ремесло инженера, когда уровень абстракции снова поднимается (как было во времена появления ассемблера, а потом высокоуровневых языков программирования).

Интересно, что в этом интервью Гради Буч заочно дискутирует с Дарио Амодеи, что в прошлом марте публично говорил, что мы можем быть в 6–12 месяцах от ситуации, когда модели будут делать end‑to‑end то, что делают software engineers, а инженеры перейдут в режим "модель пишет - я редактирую. Буч на это реагирует очень жестко и по сути: это взгляд на программирование как на набор строк кода, а не на инженерную дисциплину:)

В общем, основные тезисы интервью такие

1️⃣ Мы уже в "третьем золотом веке" - и он про системы, а не про код
Буч раскладывает историю на 3 золотых века:
1) 1940-1970 - алгоритмы и автоматизация бизнеса
2) 1970-2000 - объектные абстракции
3) 2000-сейчас - системы, где мы собираем продукты из библиотек, платформ, API, облаков - и теперь поверх всего этого появляется ИИ‑слой.
И по мнению Гради AI - это не конец профессии, а очередной скачок абстракции

2️⃣ Экзистенциальная паника - повторяющийся цикл
Когда появились компиляторы и языки высокого уровня, тоже казалось, что всё, программисты не нужны. Но индустрия не умерла - она пересобралась и пошла выше по стеку. Одна из центральных мыслей Буча: ваши инструменты меняются, но ваши проблемы - нет

3️⃣ ИИ силён там, где паттерны уже установились
Текущие инструменты типа Cursor/Claude хороши там, где задачи повторяются: типовые CRUD, стандартные интеграции, привычные веб‑паттерны. Буч прямо отмечает, что они обучены на проблемах, которые мы видели снова и снова. А вот граница интересного - в системах, контексте, компромиссах, ответственности.

4️⃣ Software engineering - это не набор кода, а баланс сил и решений
Инженерия - это баланс технических ограничений, человеческих факторов и этики, а код - лишь один из инструментов. А отсюда у нас простой вывод - ИИ может ускорить производство артефактов, но не заменить принятие решений под ограничениями.

5️⃣ Автоматизация ударит по delivery pipeline (и это нормально)
Буч отдельно отмечает, что пайплайн поставки (всё вокруг сборки/доставки/рутины) - это низко висящий фрукт для автоматизации. И людям в этих ролях может понадобиться дообучение

6️⃣ Чем выше абстракция - тем важнее фундамент
Парадоксально, но факт: когда код писать стало легче, больше ценится глубокая модель мира. Буч рекомендует усиливать фундамент и мышление системами

Кажется, что инженерам теперь качать нужно следующие навыки
- System design и distributed systems, а эта тема неплохо описана на сайте system-design.space
- Умение работать с ограничениями: стоимость, сроки, риски, легаси, безопасность, регуляторика, команда - эта тема хорошо описана там же + скоро появится новый сайт для технических лидеров в том же стиле, что я сделал system-design.space
- Навык “review & governance: проверять, тестировать, ставить ограничения, ловить неочевидные баги, которые ИИ легко генерит наряду с работающим кодом
- Доменные знания: бизнес‑контекст, который теперь ценится еще больше:)

#Architecture #Software #AI #Engineering #ML #Data #SystemDesign #DistributedSystems #History

Как пользоваться System Design Space + треки изучения (Рубрика #SystemDesign)

Сделал онбординг для сайта system-design.space. Там я рассказываю, что сайт помогает системно развивать навыки проектирования: от базовых принципов до собеседований и практических архитектурных решений.

На сайте есть разные типы материалов
- Books - конспекты ключевых книг с практическими выводами и ссылками на оригиналы.
- Cases - пошаговые разборы проектирования реальных систем с требованиями и trade-offs.
- Films - документальные материалы и интервью с контекстом, таймлайнами и полезными источниками.
- Originals - авторские главы по архитектурным подходам, паттернам и инженерной практике.
Материалы можно сохранять в закладки, чтобы возвращаться к ним (в страницах настроек).
Также есть граф знаний, который позволяет увидеть связи между главами, быстро находить смежные темы и строить маршрут от базовых концепций к более сложным.

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

#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering

CAP, PACELC и модели консистентности (Рубрика #DistributedSystems)

Сегодня вечером я буду читать лекцию с таким названием студентам Центрального Университета (хорошо, что я успел поправиться к этому моменту). В лекции мы поговорим про широко известные в узких кругах теоремы CAP и PACELC, обсудим чем consistency в этих теоремах отличается от consistency в ACID, поговорим про то, как проверяются заявленные гарантии, а в конце лекции обсудим Cassandra как пример распределенной базы данных с tunable consistency. Потом наступит время семинара, где мы попробуем эту Cassandra в деле, чтобы оценить на практике насколько весело и интересно может работать по настоящему распределенная система. В основном теория основана на статьях с моего сайта system-design.space
- CAP (Consistency, Availability, Partition tolerance)
- PACELC (if Partition then Availability or Consistency Else Latency or Consistency)
- Модели консистентности и проверка гарантий БД от Jepsen
- Cassandra

Ну и для особых эстетов можно почитать прикольный разбор "MariaDB Galera Cluster 12.1.2" от Kyle Kingsbury (Jepsen), который вышел всего 3 дня назад. Из разбора видно, что верить маркетинговым заявлениям производителей баз данных опрометчиво - надо их тезисы проверять на практике:))

P.S.
Картинка получилась у ChatGPT веселая:)

#Architecture #Management #SystemDesign #Software #Engineering #Database

Транспортные протоколы для AI-агентов (Рубрика #AI)

За последний год мы наблюдаем интересную эволюцию: AI постепенно перестаёт быть "надстройкой" над существующими интерфейсами и начинает формировать собственный слой взаимодействия. Вспомним путь, которые прошли протоколы MCP, A2A, A2UI

- MCP (Model Context Protocol)
Это попытка от Antrhropic стандартизировать, как модели получают доступ к контексту (файлы, базы, API). По сути, это про data plane для LLM
- A2A (Agent-to-Agent)
Это попытка от Google выстроить коммуникации между агентами как между равноправными участниками системы. По сути формализует диалоги, delegation, coordination. Раньше я уже сравнивал MCP и A2A протоколы
- A2UI (Agent-to-UI)
Предложенный Google протокол вокруг идеи того, что UI становится не primary интерфейсом, а "рендером" агентных действий. В итоге, пользователь взаимодействует с агентом, а не с формой/кнопками. Раньше я уже про него рассказывал
Если смотреть на тренды, то мы больше не описываем API для людей - мы описываем намерения для агентов

Продолжая эту тенденцию дальше мы приходим к идее собственного транспортного протокола для агентов, так как сейчас агентский мир живет поверх обычного http, который
- Заточен под request/response
- Плохо выражает intent (всё прячется в JSON)
- Не имеет нативной модели identity/authority для агентов
- Не оптимизирован под высокочастотный stateful трафик
И мы получаем агентные системы, которые выглядят как RPC поверх HTTP с кучей костылей.

Дальше появляется мысль вынести агентную коммуникацию в отдельный протокол ««« мы здесь
И у нас уже есть два кандидата в такой протокол: AGTP (19 марта 2026 года) и ATP (22 марта 2026 года)

1️⃣ AGTP (Agent Transfer Protocol, Chris Hood)
Этот протокол предлагает
- Новые методы вместо HTTP verbs: QUERY, EXECUTE, BOOK, ESCALATE
А значит intent становится частью протокола
- Protocol-level identity: agent_id, authority, delegation chain
А значит больше не нужно прятать это в headers/body
- Новая система статусов
Она отражает результат агентных действий, а не HTTP semantics
- Транспорт
Приоритет отдается QUIC (стримы, low latency), fallback на TCP/TLS

Основная идея в том, чтобы сделать трафик агентов наблюдаемым и управляемым на уровне сети

2️⃣ ATP (Agent Transfer Protocol, Li et al.)
Независимая инициатива, с похожими целями:
- Специализированные примитивы для agent workflows
- Поддержка stateful взаимодействия
- Фокус на interoperability между агентами разных систем

У протоколов есть как похожие черты, так и отличия

Общие черты
- Отказ от HTTP как универсального слоя
- Intent-driven коммуникация
- Встроенные identity/authority модели
- Подготовка к high-frequency agent traffic

Различия
- AGTP - более "операционный" (методы, статусы, observability) и уже предлагает более конкретную структуру протокола
- ATP - более "концептуальный" (interoperability и primitives)

Но мало ли сколько предложений о новых протоколах бывает. Конкретно эти интересны тем, что мы приходим к разделению интернета на два слоя
1. Human web (HTTP, UI, REST)
2. Agent web (AGTP/ATP, intent, delegation)
А это влияет на остальные моменты, например
- API gateway будут понимать agent traffic нативно
- В observability стеке появятся метрики уровня intent
- В security identity агентов станет first-class
- А SDK перестанут быть "обёртками над REST"

Если эти протоколы взлетят, нас ждёт
- Отдельные agent-native API gateways
- Маршрутизация по intent, а не по URL
- Policy engines на уровне агентных действий
- Встроенная экономика взаимодействия агентов (оплата, квоты, ...)
- Тесная интеграция с DNS и service discovery

Нам как архитекторам придется думать не только про API, но и про семантику действий. Архитектуры будут смещаться от request/response к workflow orchestration. Observability нужно будет строить вокруг intent и outcome, а не только latency, ну и конечно нам придется построить новый платформенный слой под агентов:)

#AI #Architecture #DistributedSystems #Network #SystemDesign #Software

From Writing Code to Managing Agents. Most Engineers Aren't Ready | Stanford University, Mihail Eric (Рубрика #Engineering)

Интересное интервью Mihail Eric, Head of AI at Monaco и лектора Стэнфорда, где он ведёт курс "CS146S: The Modern Software Developer". Mihail Eric интересно рассказывает про то, куда реально двигается разработка софта. Основная мысль про то, что профессия не исчезает, но центр тяжести уходит от ручного написания каждой строчки к оркестрации AI-агентов, декомпозиции задач, проверке результатов и проектированию среды, в которой агентам можно доверять. Собственно, сам курс "CS146S: The Modern Software Developer" как раз про это.

В этом интервью 15-минутном интервью были несколько интересных мыслей

1️⃣ Eric объясняет почему junior-рынок так штормит тремя факторами
- Перегретый найм после 2021 года и последующие сокращения
- Резкий рост числа CS-выпускников
- AI, из-за которого компании всё чаще думают не "кого ещё нанять", а "сколько AI-native инженеров нужно, чтобы закрыть тот же объём работы"

2️⃣ Eric объясняет, а кто такой AI-native engineer
- Это не просто про промпт инженер, а скорее разработчик с нормальной базой в system design, алгоритмах и традиционной разработке
- Этот инженер должен уметь работать с агентскими workflow
По мнению Eric основная ошибка - это попытка сразу запускать много агентов. Но лучше начинать наоборот: сначала один агент на один workflow, потом постепенно добавлять только изолированные задачи и лишь затем масштабировать оркестрацию

3️⃣ Eric рассказывает про дружелюбную для агентов кодовую базу
- Для агента тесты - это не "nice to have" фича, а фактически контракты
- Если тестов мало, README устарел, а одинаковые сущности создаются разными паттернами в разных местах, то агент начинает гадать - и очень быстро начинает плодить ошибки.
В итоге, тексты, документация и единые паттерны базы - это не просто инженерная гигиена, а просто база для AI-native разработки

4️⃣ Eric отмечает, что мульти-агентные workflows больше похожи на менеджмент, чем на классическое программирование
Нужно уметь быстро переключать контекст, держать в голове, чем занят каждый агент, понимать, где он застрял, и мягко возвращать его в правильную траекторию. По сути, сильный AI-native engineer - это уже немного менеджер команды из агентов:)

5️⃣ Eric отмечает важность вкуса продуктового и инженерного
Функциональный продукт и действительно сильный продукт разделяет не только корректность кода, но и желание пройти "последнюю милю": сделать фичу устойчивее, полезнее, глубже, довести UX и robustness. Eric связывает это с постоянным экспериментированием: даже команды, которые строят AI-инструменты, сами всё время переписывают и переизобретают свои workflow.

В общем, автор за 15 минут продал мне свой курс про современную разработку софта, лекции которого уже доступны на Youtube (правда, это не официальная версия, которую я не нашел, а сгенерированная через notebook lm на основе материалов курса)

#Agents #Software #Engineering #Management #DistributedSystems #SystemDesign #AI

System-Design.Space (Update) (Рубрика #SystemDEsing)

В последние недели я не останавливался с доработками своего сайта system-design.space. И сегодня я решил поделиться тремя ключевыми изменениями

1) Я поменял дизайн главной страницы, чтобы прямо на ней был блок с онбордингом и описанием всех возможностей доступных на сайте:
- Выбор трека изучения
- Изучения графа знаний
- Доступ на страницу со всеми материалами с поиском и фильтрацией по ним
Надеюсь, что теперь сайт станет понятнее и удобнее для пользователей, а то я посмотрел ряд сессий из Яндекс Метрики, где пользователи попадали на сайт и как будто не могли понять а что на нем есть и дальше просто уходили

2) Теперь в каждой главе в начале есть блок, в котором рассказывается о чем глава, почему это полезно для проектирования систем, а также как эти знания можно использовать на интервью - это моя попытка объяснить почему главу стоит прочитать. Если вы по описанию видите, что глава вам не особо полезна или интересна, то сразу можно пролистнуть на следующую

3) Я сам устал от артефактов в мобильной верстке, поэтому мы с OpenAI Codex написали скрипты для e2e тестов layouts в десктопном и мобильном режиме и поправили 90+ проблемных глав. Теперь на мобилке должно быть гораздо приятнее изучать этот сайт.

Было еще какое-то количество небольших изменений, но эти показались мне достойными упоминания.

#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview

[1/2] Hands-On RAG for Production (Рубрика #AI)

С интересом прочел доступные главы этой книги, что находится в процессе написания. Основная идея авторов Ofer Mendelevitch и Forrest Bao была в том, чтобы рассказать про retrieval augmented generation как про инженерную систему и рассмотреть вопросы приема данных в платформу, прав доступа, latency ответов, автоматического оценивания, приватности и так далее. Это сильно отличает книгу от других, где RAG выглядит просто еще один паттерн поверх AI, но это и понятно, ведь авторы работают в Vectara, компании, что делает платформу для агентов, а также RAG as a service (поэтому и часть практических примеров в книге связана с этой платформой).

В общем, книга по задумке авторов попадает в самую болезненную точку рынка: разрыв между "демо работает" и «система переживает production, аудит, рост нагрузки и вопросы от security». Это и делает её важной не только для инженеров, но и для технических руководителей, не ради слова RAG, а ради инженерной дисциплины вокруг него (я примерно поэтому и взялся читать книгу). Если идти по доступным главам, то логика авторов прослеживается хорошо: сначала они собирают базу, а потом быстро уводят читателя из мира RAG на коленке в мир ограничений вокруг продакшена. Давайте посмотрим на главы пристальнее

1) "Introduction to Retrieval Augmented Generation (RAG)"
Это, по сути, фундамент: что RAG решает, где он реально лучше "голой" модели, и почему его так любят в enterprise-сценариях. Например, здесь автоы сравнивают RAG и fine-tuning моделей.
2) "Advanced RAG"
В этой главе начинается интересное обсуждение того, что отличает базовый pipeline от реально полезной системы. То есть не просто dense retrieval, а более сильный retrieval stack, reranking, chunking, query rewriting, гибридные схемы и прочая инженерия качества.
3 и 4) "Deploying RAG to Production" и "The RAG Platform" - это центральная часть книги. Именно здесь RAG перестаёт быть проектом на поиграться и становится системной задачей со своим набором ограничений и требований: latency, privacy, explainability, prompt design, compliance, доступы к данным, архитектурные компромиссы, build-vs-buy. А четвертая глава "The RAG Platform" особенно хороша тем, что показывает, что зрелый RAG почти всегда превращается не в одну фичу, а в платформенный слой, который начинает обслуживать несколько продуктов и команд.

В посте-продолжении я поделюсь мнением про оставшиеся главы книги и расскажу для кого она будет полезна.

#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents

[2/2] Hands-On RAG for Production (Рубрика #AI)

Заканчивая обзор это крутой книги про RAG, что находится в процессе написания.

5) "Evaluating your RAG Application" - эта глава обязательна для прочтения тем, кто планирует докатить RAG на production. Авторы упоминают про метрики вроде hallucinations, response quality, latency и cost. И не только упоминают, но и рассказывают про способы измерения качества retrieval и генерации. По-факту, тут идет рассказ про стандартные метрики поиска (precision, recall, f1, метрики с учетом порядка элементов), а также про точность генерации (утилизация контекста, точность ответов, консистентность ответов, отсутствие галлюцинаций, точность цитат), а также предубеждения (по расе, полу и так далее). А также подходы к e2e оцениваниют при помощи фреймворков: Open-RAG-EVAL, RAGAs, DeepEval. Ну и напоследок как учитывать фидбек людей (условно пальцы вниз и вверх, которые вы видели в чатиках ChatGPT, Perplexity, ...)

6) "From RAG to AI Agents" - здесь речь идет про retrieval, который перестаёт быть конечным продуктом и становится частью более длинного workflow. То есть RAG - уже не только "найди и ответь", а "найди, проверь, спланируй, вызови инструмент, верни результат". Это очень верно для текущего времени, где агенты без качественного retrieval быстро превращаются в дорогую импровизацию.

7 и 8) "Multimodal RAG" и "Knowledge Enhanced RAG" делают книгу ещё полезнее для реальных корпораций. Это важно для всех, кто работает с PDF, таблицами, диаграммами, изображениями, полуструктурированными документами и сложными knowledge domains, где одной embedding similarity уже мало.

P.S.
Если сравнить эту книгу с другими, о которых я рассказывал, то получается такая картина

- "AI Engineering" - это широкая карта всей дисциплины и ответ на вопрос, а что вообще такое современная AI-разработка и из каких слоёв она состоит. На этом фоне "Hands-On RAG for Production" выглядит уже не как обзор всей системы, а как очень подробный разбор ее части - production RAG.
- "Prompt Engineering for LLMs" учит понимать архитектуру LLM, строить prompt strategy, правильно собирать context elements и использовать техники вроде few-shot, chain-of-thought и RAG. Поэтому "Prompt Engineering for LLMs" - это книга про интерфейс между человеком, контекстом и моделью, а "Hands-On RAG for Production" - про retrieval/platform layer, который этот контекст делает надёжным в проде.

#AI #Engineering #Software #DistributedSystems #SystemDesign #Database #Search #Agents

System Design Space (Рубрика #Architecture)

Последние месяцы мало рассказывал про свой пет-проект system-design.space, но я не переставал над ним работать:)
По-факту, было 3 основных трека

1️⃣ Улучшение языка изложения - я хотел избавиться от runglish по всему сайту. Многие из вас говорили о том, что это мешает изучению материалов. В итоге, я сделал специальный подход с терминологическим словарем и рефакторингом проекта. Сейчас термин в первый раз внутри главы сопровождается английским термином в скобках + при наведении можно посмотреть расшифровку. Дальше по главе он идет уже на русском. Это касается почти всех терминов, но акронимы все равно остаются на английском

2️⃣ Добавление покрытия материалов по разным темам в основном вокруг проектирования ML/AI систем

3️⃣ Сборка книжки и подача ее в издательство - теперь у меня есть черновик, который возможно превратится в книгу.
В книге пока три основные части
- Принципы найма и проведения собесов в bigtech - мои статьи про найм у нас
- Принципы проектирования - тут тоже я пилил статьи и даже обучающие курсы по архитектуре
- Задачи на проектирование из домена ML/AI, описание и решение которых оформлено в том стиле, что мы используем внутри себя (по 7-шаговому фрймворку). Я выбрал задачки из этого домена для того, чтобы читатели разобрались на практике с тем, как работают эти технологии и что там нет магии, понимали их ограничения и рабочие режимы, а также лучше понимали как встраивать эти возможности в свои сервисы.
В книге есть еще 3 приложения
- Разборы других материалов на тему system design (книг и курсов)
- Немного про документалки о технологиях и зачем их смотреть
- Терминологический словарь
А в конце еще есть список ссылок на литературу

#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview

Материалы по прямому эфиру с Сергеем Барановым про AI в архитектуре (Рубрика #Architecture)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Сергеем Барановым (@blog_sb), партнером компании Скрамтрек и организатором конференции ArchDays (@blog_sb):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
Как раз видео на выходные + если кто-то хочет почитать оригинальное исследование, то вот оно + мой краткий разбор

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems