Сайт по system design (Рубрика #Architecture)

Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.

Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

[1/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

15 декабря 2025 команда A2UI в Google публично выложила проект A2UI (Agent-to-User Interface) - открытый формат + библиотеки рендеринга, чтобы “удалённые” AI‑агенты могли возвращать сложные интерфейсы (формы, карточки, списки, кнопки) как данные, а не как исполняемый код. Этот протокол призван решить проблему текстовых чатов, когда простые пользовательские действия (забронировать столик, заполнить поля, выбрать время) превращаются в долгую переписку “вопрос‑ответ‑уточнение”. A2UI предлагает вместо этого дать агенту возможность сгенерировать контекстную форму/карточку из каталога компонентов и отрисовать её в вашем приложении. Сам протокол доступен на GitHub.

По сути это работает примерно следующим образом - агент генерирует декларативное описание UI в JSON, клиент рендерит это нативными компонентами своего приложения.
Ключевые принципы (сформулированы в README проекта):
- Security‑first: агент не присылает JS/HTML/код. Он присылает данные, которые проходят валидацию, а UI строится из каталога заранее разрешённых компонентов (Button/Card/TextField/и т.д.). Это снижает риск UI‑инъекций и “случайного RCE через UI”
- LLM‑friendly + инкрементальные апдейты: UI описывается “плоской” структурой (adjacency list) с ID‑ссылками, поэтому агент может стримить интерфейс и патчить отдельные компоненты по ID, не пересылая всё дерево
- Framework‑agnostic: один и тот же A2UI‑пейлоад может быть отрендерен в разных клиентах (web/mobile/desktop) — потому что “как рисовать” решает клиент
- Transport‑agnostic: A2UI - это формат/контракт сообщений, его можно гонять поверх разных “транспортов” (включая A2A и AG‑UI)

На практике (в версии v0.8, stable/public preview) сообщения обычно идут как JSON Lines (JSONL): одна строка = одно сообщение. Есть 4 ключевых типа:
- beginRendering
- surfaceUpdate
- dataModelUpdate
- deleteSurface
Сам стрим может выглядеть примерно так

{"surfaceUpdate": {"surfaceId":"main","components":[ ... ]}}
{"dataModelUpdate": {"surfaceId":"main","contents":[ ... ]}}
{"beginRendering": {"surfaceId":"main","root":"root-component"}}

Но надо отметить, что спека все еще дорабатывается и между v0.8 (stable) и v0.9 (draft) уже есть изменения в деталях и даже названиях envelope‑сообщений

Теперь давайте обсудим, а почему этот протокол нам интересен и чем он лучше альтернатив.
1. Одной из альтернатив является генерация HTML/JS/React‑кода агентом.
Здесь у нас есть проблема с безопасностью и контролем - вам либо нужно исполнять непроверенный код, либо городить тяжёлую песочницу. В A2UI у нас вместо кода данные, а рендеринг идет только из доверенного каталога компонентов.
2. Другой алтернативой являются iframe‑подходы / “UI как ресурс” (например, MCP Apps)
В статье Google прямо сравнивает A2UI с MCP Apps: там UI часто приходит как “opaque payload” (например HTML) и рендерится в sandboxed iframe. Но A2UI выгодно отличается “native‑first” подходом: агент отправляет blueprint нативных компонентов, и UI наследует стиль/дизайн‑систему/доступность хост‑приложения, вместо отдельного “мини‑веба в iframe”.
3. Платформенные end2end экосистемы (например, OpenAI ChatKit)
Плюс таких решений - интеграция в рамках одной платформы. Минус - переносимость и работа в мульти‑агентных сценариях с разными вендорами. A2UI целится в переносимый UI‑контракт для ваших собственных клиентов и enterprise‑mesh сценариев.
4. Просто возьмём AG‑UI и хватит
AG‑UI решает вопросы интеграция агента и UI), а A2UI - описывает сам формат UI‑ответа. Google явно позиционирует A2UI как комплементарный слой: подключили хост через AG‑UI → можете использовать A2UI как формат для UI‑ответов, в том числе от внешних агентов

Продолжение о том, а почему этот проект так интересен в посте-продолжении.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems

[2/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

В продолжении обсуждения протокола A2UI от Google мы рассмотрим, а почему он может быть интересен создателям genAI приложений для пользователей.

Если смотреть на публичные сигналы, проект реально подхватили:
1. GitHub traction. За полтора месяца проект набрал 10.9k звезд, 810 forks, 66 issues, 80 PR, 332 commits, 31 contributor в основном репозитории
2. Официальные туториалы Google. В документации для Google Workspace появился quickstart “Build a Google Chat app with an Agent2UI agent” (обновлён 2026‑01‑27), с развёртыванием агента через ADK и хостингом в Vertex AI Agent Engine. Это хороший индикатор, что A2UI продвигают как практический способ строить UI‑ответы агентов внутри Workspace/Chat‑сценариев.
3. Экосистема вокруг. Появляются сторонние реализации/порты:
- a2ui-rails - порт в Ruby/Rails
- A2UI-for-Google-Apps-Script - демо/адаптация под Apps Script/Workspace
- Отдельные упоминания и интеграционные запросы в других agent‑framework репозиториях тоже всплывают (feature requests/discussions)

И отдельно: сам проект помечен как Early stage public preview (v0.8), при этом параллельно ведётся v0.9 (draft) - то есть активная фаза “формат шлифуется”.

Отдельно надо подсветить почему это должно быть инженерам
- Нормальный контракт между “мозгом” и UI: агент не “рисует DOM”, а отправляет декларативные апдейты, которые ваш клиент валидирует и рендерит. Это лучше ложится на архитектуру “удалённый агент / недоверенная граница”
- Инкрементальность и патчи: можно стримить UI и менять только нужные куски по ID, вместо “перерисовать всё”
- Переиспользование дизайн‑системы: UI остаётся нативным (ваши компоненты/темизация/а11y), а агент лишь “просит” собрать композицию
- Прагматичная интеграция: есть референсные рендереры (Lit/Angular/Flutter), есть понятный quickstart с демо‑агентом

Для техлидов и engineering менеджеров это может быть интересно по другим причинам
- Скорость поставки фич: вместо того чтобы каждый раз вручную проектировать “формочку под новый workflow”, часть UX можно делегировать агенту, но в рамках жёсткого каталога компонентов и правил
- Управляемый риск: “данные вместо кода” = проще проходить security review, проще ограничивать поверхность атаки, проще объяснять границы доверия между командами/вендорами
- Стандартизация для мульти‑агентных сценариев: когда разные агенты/под‑агенты (внутренние и внешние) должны отдавать UI в единый клиент, формат уровня A2UI снижает интеграционный ад
- Сигналы зрелости: быстрорастущий репозиторий + официальный quickstart в Google Workspace доках + параллельная работа над спецификацией (v0.8 stable / v0.9 draft) — это похоже на проект, который реально хотят “довести до v1”

Если вы сейчас строите agentic‑продукт и упираетесь в “чат вместо продукта”, A2UI выглядит как очень практичный способ превратить ответы агента в управляемые, нативные, безопасные UI‑сессии - и при этом не завязаться на один конкретный фронтенд‑стек.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems

Update по System Design Space (Рубрика #Engineering)

Я запустил этот сайт чуть больше недели назад и продолжил его активно дорабатывать и решил поделиться lessons learned.
- Дорабатывать сайт ипользуя только Lovable дорого - кредиты улетают как не в себя - я прошел такой путь за месячную подписку всего за полтора месяца 0$ -> 25$ -> 50$ -> 100$ -> 200$
- Как второй и основной помощник я сейчас использую OpenAI Codex, где подписки в 200$ хватает как на веб, deep research, так и на написание кода (сразу для целой пачки ресурсов)
- Я добавил очень много новых глав + отдельный раздел, что посвящен документальным фильмам про технологии
- Для сложных тем я сделал визуализации архитектуры и процесса работы - смотрите примеры из части с кейсами
- Я добавил светлую тему, оглавление, поменял верстку под мобилу и еще кучу всего
- Сайт успел за неделю полежать пару раз. Один раз мы с Codex оптимизировали сборку и lazy загрузку React, что локально все работало, а на внешнем хостинге нет - пришлось откатить эту оптимизацию. Второй раз была проблема с DNS - я забыл подтвердить email регистратору доменных имен и дальше делегирование сайта было преостановлено (дальше прожал кнопочку подтверждения из email и буквально всего через 2 часа все вернулось, а могло и через 2 дня)
- Как-то я попросил отрефакторить проект и агент ушел локально колбасить что-то на всю ночь - утром пришел проверил, сделал несколько фиксов и все полетело
- Тесты у меня есть, но из-за того, что я часто меняю внешний вид сайта, то я часто их просто заново гененрирую, а не прогоняю для проверки (главы - это отдельные ts файлы, поэтому изменения обычно хорошо локализованы и дают мало внешних эффектов)
- Я занимаюсь этим по выходным, а также по вечерам после работы и это затягивает - иногда в 2 часа ночи ловлю себя на мысли, что надо выдать задачку помасштабнее и наконец-то пойти спать:)

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

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Local-First Software: Taking Back Control of Our Data | a mini-doc (Рубрика #DistributedSystems)

Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.

Основные идеи концепции такие
1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа.
2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным.
3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы.
4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.

Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее
- Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета)
- Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка.
- Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена.
- Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака.
- Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.

В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.

P.S.
Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)

P.P.S.
Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.

#DistributedSystems #Architecture #SystemDesign #Software #Databases

Update: SDS (System-Design.Space)

С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.

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

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

[1/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary)

С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения Nvidia из стартапа на грани банкротства в компанию стоимостью $3 триллиона . Фильм охватывает путь от основания в 1993 году до текущего доминирования в области AI . Мне было интересно посмотреть, а какие этапы проходила компания и какие выводы можно почерпнуть нам как инженерам и техническим руководителям

Основание и первые годы
Nvidia была основана тремя инженерами - Дженсеном Хуангом, Крисом Малачовски и Кёртисом Примом - которые познакомились работая в Sun Microsystems и LSI Logic . Легендарная встреча состоялась в ресторане Denny's в Сан-Хосе, где за чашками кофе они обсуждали будущую компанию день за днем . Их ставка была на 3D-графику для PC и видеоигр, хотя на тот момент они даже не видели персональный компьютер . Название Nvidia произошло от латинского слова "invidia" (зависть), а также от сокращения NV ("next version"), которое основатели использовали при сохранении файлов . С начальным капиталом всего $40,000 и последующим финансированием $20 млн от Sequoia Capital, они начали свой путь .

Провал и чудесное спасение
Первый продукт NV1 (1995) оказался катастрофой: из 250,000 чипов, отправленных партнёру Diamond Multimedia, вернулось 249,000 . Проблемы были в том, что чип использовал quadratic primitives вместо triangle primitives, которые стали стандартом Microsoft DirectX, плюс был слишком дорогим . После отмены контракта с Sega на NV2, у компании осталось финансирование только на один месяц зарплат . Riva 128 (август 1997) стал продуктом, спасшим Nvidia - за четыре месяца он продался тиражом в миллион единиц, в отличие от NV1, который продал едва тысячу . С тех пор в компании существует неофициальный девиз: "Мы всегда в 30 днях от банкротства". Интересно, что в моем первом компьютере был чип riva tnt2, то есть я познакомился с творчеством ребят еще до начала 21 века:)

Прорыв и IPO
GeForce 256 (1999) стал первым в мире GPU с программируемым ускорителем - это был прорыв в концепции ускоренных вычислений . В январе 1999 года Nvidia провела IPO, что дало компании больше капитала и публичности . Следующим большим шагом стал контракт с Microsoft на $200 млн на разработку чипов для оригинального Xbox .

Поворот к AI
Самое интересное решение было принято в середине 2000-х: релиз CUDA в 2006 году - платформы параллельных вычислений, которая позволила использовать GPU не только для графики . Профессор Стэнфорда Эндрю Нг вспоминает, что уже в 2008 году его студенты экспериментировали с CUDA для deep learning и получали ускорение в 10-100 раз . Это был огромный риск: в конце 2000-х никто не знал, станет ли AI прибыльным . Nvidia приняла решение о масштабной трансформации компании, добавляя затраты, нанимая людей и отвлекая внимание от основного бизнеса в gaming и компьютерной графике . Хуанг описал это как "wholesale pivot" - полную переориентацию всей компании .

Интересно, что у меня был коллега в МФТИ, которого мы взяли пилить всякие веб-сайты, а он парарллельно занимался CUDA по научной траектории и в какой-то момент сказал нам ариведерчи и ушел заниматься CUDA фултайм.

Дальше карта AI пошла хорошо - в 2012 году случился AlexNet и произошел старт “современного AI”. NVIDIA прямо отмечает, что прорыв AlexNet стал спусковым крючком эры modern AI, и GPU оказался в центре этой волны. А про инсайты и выводы из этой документалки мы поговорим в следующий раз.

#Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems

Dyad - local‑first AI app builder: как Lovable/Bolt, только на своем компьютере (Рубрика #AI)

Я как-то уже рассказывал про продукт Lovable, этакий "AI app builder", в котром написал запрос → получил изменения кода → увидел превью → опубликовал на прод. Собственно, то Dyad делает ровно этот цикл, но локально. В самом репозитории Dyad прямо позиционируется как local/open‑source альтернатива Lovable/v0/Bolt (и в целом - альтернативный путь по сравнению с облачными платформами).

Кстати, про подход local-first я тоже уже рассказывал, когда делал саммари на документалку и в dyad есть все признаки этого подхода
- Код и проект у вас на диске: без "платформенной клетки", можно импортировать/экспортировать и свободно переходить между Dyad и обычным dev‑workflow
- Bring your own keys: вы сами подключаете нужных провайдеров и модели (OpenAI/Google/Anthropic и т.д.), без принудительного вендор‑лок‑ина
- Расширяемость: можно добавлять инструменты через MCP‑серверы и жить на шаблонах (templates) под разные JS‑стеки

Функциональность Dyad похожа на Lovable и включает в себя
- Full‑stack приложения через Supabase: быстро подключить базу, auth и server functions
- Security review на базе AI: запускаете проверку, получаете находки с уровнями критичности и можете попросить AI исправить конкретную проблему; правила проверки можно подкрутить через SECURITY_RULES.md
- Автоматическое versioning: каждое AI‑редактирование - это новая версия; по сути это git‑коммит. Можно открыть список версий и “restore” до последнего удачного состояния (механика похожа на git revert, история при этом не теряется)
- Публикация: “publish anywhere” - GitHub/Vercel или ваш стек

Если говорить про архитектуру, то это устроено следующим образом
Dyad - это electron‑приложение:
- UI живёт в renderer process,
- Доступ к файловой системе и "применение изменений" - в main process,
- Общение идёт через IPC

Ключевой трюк AI-редактирования в том, что модель отвечает не "просто текстом", а в XML‑подобном формате команд. UI стримит и красиво показывает ответ, а затем main‑процесс (через response processor) применяет команды к проекту: создать/изменить/удалить файлы, добавить npm‑пакеты и т.п.
Отдельно отмечается, что Dyad не стремится быть максимально "агентным" как Cursor, потому что сложные agentic‑циклы быстро становятся дорогими - поэтому чаще это “один запрос → один аккуратный проход”, с опциональным авто‑фиксом TypeScript ошибок.

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

#AI #Engineering #Software #Architecture #DistributedSystems #Agents #ML

Inside Argo: Automating the Future (Рубрика #DevOps)

Если у вас Kubernetes в проде, то этот фильм про опенсорс проект может принести пользу - это история того, как Argo вырос из workflow‑движка в набор инструментов для автоматизации деплоев и процессов вокруг них (Workflows / CD / Rollouts / Events). В кадре появляются ключевые люди, что стояли у истоков Argo и которые в 2017 году запустили Argo и как вокруг него постепенно появлялось community и набор связанных инструментов. Также мы видим почему GitOps + Argo стали де‑факто стандартом для "предсказуемых" деплоев в cloud‑native мире.

Для инженеров просмотр может быть интересен, так как
- Это не "маркетинг инструмента, а кейсы взросления опенсорса: комьюнити, мейнтейнерство, стандарты качества/безопасности, и как из внутренней разработки получается индустриальный инструмент
- Это про масштаб: Argo прошёл путь CNCF Incubating (2020) → Graduated (2022), и CNCF отмечает сильную индустриальную динамику принятия инструмента (adoption)

На практике этот инструмент позволяет разработчикам иметь меньше ручных релизов и “магии” в пайплайнах → больше декларативности, повторяемости и отладки через Git как source of truth. А руководителям платформенных команд это дает понимание, что delivery‑контур - это продукт. Инструменты типа Argo ценны ровно настолько, насколько вы вкладываетесь в guardrails, стандарты и поддержку внутренней платформы.

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

#Kubernetes #DevEx #PlatformEngineering #Software #Architecture #DistributedSystems

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