Update: SDS (System-Design.Space)
С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.
В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.
В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
System Design Space
System Design Space — Главная, граф знаний, треки и материалы
Главная страница System Design Space: быстрый старт, граф знаний, библиотека материалов, персональные треки и трекинг прогресса.
1🔥58❤11⚡3
[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
С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения 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
YouTube
Nvidia's Explosive Rise from Zero to Trillions (Documentary)
✦ Learn about Nvidia's incredible journey from a small startup to a $3 trillion company in this documentary. Explore Nvidia's impact on technology, AI, and more, as well as the fascinating story of founder Jensen Huang. If you're interested in Nvidia stock…
🔥11❤5👍4
[2/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary)
Продолжая рассказ про историю Nvidia надо отметить инсайты фильма, которые пришли ко мне после его просмотра
1️⃣ Платформа съедает продукт
NVIDIA выиграла не только “чипом”, а тем, что сделала программируемую платформу: CUDA - это не “одна библиотека”, а экосистема (компилятор, тулкит, профилинг, библиотеки). В итоге возникает “липкость” и сетевой эффект вокруг железа - редкость для hardware‑бизнеса.
2️⃣ Ставка на рынки с нулевым размером может быть рациональной
Большие pivots компании (3D‑графика для PC, потом AI) - это ставки на “zero‑billion dollar markets”. То есть не про хайп, а про умение увидеть будущий сдвиг вычислительной парадигмы.
3️⃣ Программируемость = мультипликатор
GeForce 256 была важна не только как ускорение рисования, а как шаг к программируемому ускорителю. Дальше из этого выросла CUDA и общие вычисления
4️⃣ Инженерная дисциплина под давлением решает
История “у нас один шанс на tape‑out” и ускорение цикла разработки - это не романтика, а практическая управленческая инженерия: сокращать feedback loop любой ценой.
5️⃣ AI‑инфраструктура - это “система систем”
DGX (системы) + Mellanox (сеть) = понимание, что для AI важны не только FLOPS, но и: память, интерконнект, сеть, софт‑стек, инструменты, поставки. Собственно Mellanox был куплен Nvvidia за $7 млрд в 2020 году, когда ребята поняли, что им этого не хватает.
Для технических лидеров мне кажется полезным будет подумать над такими тезисами
1) Стратегия вычислений = стратегия бизнеса
Если у вас AI‑фичи в roadmap - у вас появляется новый ресурс: GPU‑время/память/интерконнект, и этим нужно управлять как бюджетом и SLA.
2) Платформенная команда - это не роскошь
Нужны люди/команда, которые делают “внутренний CUDA” вашей компании:
- Шаблоны пайплайнов,
- Инфраструктура обучения/инференса,
- Наблюдаемость (стоимость, утилизация, узкие места),
- Guardrails по качеству/безопасности.
3) Управляйте vendor lock‑in как риском, а не как идеологией
CUDA‑экосистема реально мощная - и именно это даёт NVIDIA рычаг.
- Оставляйте “точки выхода” (абстракции, ONNX/portable‑слои где уместно, контрактные тесты производительности),
- Держите план B по инфраструктуре (облако/он‑прем/альтернативные ускорители),
- Фиксируйте метрики стоимости/латентности как продуктовые KPI.
4) "Полный стек" важнее "самого быстрого GPU"
- Покупка Mellanox и ставка на DGX - хороший сигнал: производительность AI‑системы часто упирается в сеть/IO/оркестрацию, а не в “ещё 10% TFLOPS”.
🧐 После просмотра можно пройтись по таком мини‑чеклист для команды
1. Посчитать стоимость 1 GPU‑часа (или inference‑1000 req) и сделать её видимой.
2. Ввести профилирование как обязательный шаг перед релизом ML‑фич.
3. Определить, где вам нужна "портируемость", а где можно идти в максимальную оптимизацию под конкретный стек.
4. Проверить узкие места: сеть, storage, батчинг, очереди.
5. Обновить hiring/skill‑matrix: нужен ли вам performance engineer / ML systems engineer?
6. Зафиксировать “exit strategy” от критических зависимостей (не завтра, но чтобы она была на бумаге).
#Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems
Продолжая рассказ про историю Nvidia надо отметить инсайты фильма, которые пришли ко мне после его просмотра
1️⃣ Платформа съедает продукт
NVIDIA выиграла не только “чипом”, а тем, что сделала программируемую платформу: CUDA - это не “одна библиотека”, а экосистема (компилятор, тулкит, профилинг, библиотеки). В итоге возникает “липкость” и сетевой эффект вокруг железа - редкость для hardware‑бизнеса.
2️⃣ Ставка на рынки с нулевым размером может быть рациональной
Большие pivots компании (3D‑графика для PC, потом AI) - это ставки на “zero‑billion dollar markets”. То есть не про хайп, а про умение увидеть будущий сдвиг вычислительной парадигмы.
3️⃣ Программируемость = мультипликатор
GeForce 256 была важна не только как ускорение рисования, а как шаг к программируемому ускорителю. Дальше из этого выросла CUDA и общие вычисления
4️⃣ Инженерная дисциплина под давлением решает
История “у нас один шанс на tape‑out” и ускорение цикла разработки - это не романтика, а практическая управленческая инженерия: сокращать feedback loop любой ценой.
5️⃣ AI‑инфраструктура - это “система систем”
DGX (системы) + Mellanox (сеть) = понимание, что для AI важны не только FLOPS, но и: память, интерконнект, сеть, софт‑стек, инструменты, поставки. Собственно Mellanox был куплен Nvvidia за $7 млрд в 2020 году, когда ребята поняли, что им этого не хватает.
Для технических лидеров мне кажется полезным будет подумать над такими тезисами
1) Стратегия вычислений = стратегия бизнеса
Если у вас AI‑фичи в roadmap - у вас появляется новый ресурс: GPU‑время/память/интерконнект, и этим нужно управлять как бюджетом и SLA.
2) Платформенная команда - это не роскошь
Нужны люди/команда, которые делают “внутренний CUDA” вашей компании:
- Шаблоны пайплайнов,
- Инфраструктура обучения/инференса,
- Наблюдаемость (стоимость, утилизация, узкие места),
- Guardrails по качеству/безопасности.
3) Управляйте vendor lock‑in как риском, а не как идеологией
CUDA‑экосистема реально мощная - и именно это даёт NVIDIA рычаг.
- Оставляйте “точки выхода” (абстракции, ONNX/portable‑слои где уместно, контрактные тесты производительности),
- Держите план B по инфраструктуре (облако/он‑прем/альтернативные ускорители),
- Фиксируйте метрики стоимости/латентности как продуктовые KPI.
4) "Полный стек" важнее "самого быстрого GPU"
- Покупка Mellanox и ставка на DGX - хороший сигнал: производительность AI‑системы часто упирается в сеть/IO/оркестрацию, а не в “ещё 10% TFLOPS”.
1. Посчитать стоимость 1 GPU‑часа (или inference‑1000 req) и сделать её видимой.
2. Ввести профилирование как обязательный шаг перед релизом ML‑фич.
3. Определить, где вам нужна "портируемость", а где можно идти в максимальную оптимизацию под конкретный стек.
4. Проверить узкие места: сеть, storage, батчинг, очереди.
5. Обновить hiring/skill‑matrix: нужен ли вам performance engineer / ML systems engineer?
6. Зафиксировать “exit strategy” от критических зависимостей (не завтра, но чтобы она была на бумаге).
#Documentary #Infrastructure #AI #ML #Engineering #Software #Leadership #Startup #DistributedSystems
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Книжный куб
[1/2] Nvidia’s Explosive Rise from Zero to Trillions (Рубрика #Documentary)
С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения Nvidia из стартапа на грани банкротства в компанию стоимостью $3 триллиона…
С большим интересом я посмотрел этот документальный фильм рассказывает впечатляющую историю превращения Nvidia из стартапа на грани банкротства в компанию стоимостью $3 триллиона…
❤4👍3🔥3
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 исправить конкретную проблему; правила проверки можно подкрутить через
- Автоматическое versioning: каждое AI‑редактирование - это новая версия; по сути это git‑коммит. Можно открыть список версий и “restore” до последнего удачного состояния (механика похожа на
- Публикация: “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
Я как-то уже рассказывал про продукт 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
Telegram
Книжный куб
История стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год (Рубрика #Startup)
Компания Lovable (изначально известная как проект GPT Engineer) была официально основана в ноябре 2023 года в Стокгольме. Ее основали Anton Osika, бывший…
Компания Lovable (изначально известная как проект GPT Engineer) была официально основана в ноябре 2023 года в Стокгольме. Ее основали Anton Osika, бывший…
❤8⚡4🔥2
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
Если у вас 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
YouTube
Inside Argo: Automating the Future
Set in 2017, “Inside Argo: Automating the Future,” is a thought-provoking documentary film that chronicles the journey of a groundbreaking open source innovation that revolutionized Kubernetes workflows.
This documentary follows the project teams as they…
This documentary follows the project teams as they…
❤6👍5🔥1
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
В этом видео Лэсли Лэмпорт за 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
YouTube
The Man Who Revolutionized Computer Science With Math
Leslie Lamport revolutionized how computers talk to each other. The Turing Award-winning computer scientist pioneered the field of distributed systems, where multiple components on different networks coordinate to achieve a common objective. (Internet searches…
❤13🔥6👍3
История 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
Интересное видео про историю операционных систем от канала 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
YouTube
История Linux и UNIX! Кто породил ВСЕ современные системы!
Получите месяц Толка бесплатно по промокоду PRO — https://bit.ly/3tzEklU
Недорогой монитор QHD https://www.citilink.ru/product/monitor-sunwind-27-sun-m27bg130-chernyi-ips-8ms-16-9-hdmi-mat-250cd-1772349/?utm_source=yt_blogger_prohitech&utm_medium=display…
Недорогой монитор QHD https://www.citilink.ru/product/monitor-sunwind-27-sun-m27bg130-chernyi-ips-8ms-16-9-hdmi-mat-250cd-1772349/?utm_source=yt_blogger_prohitech&utm_medium=display…
❤10👍6🔥3
Дискуссия с Гришей Скобелевым про подготовку к 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
Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space
Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру
Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.
Встречаемся завтра c кофе ☕️ в 11:00 на YouTube
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Telegram
{ между скобок } анонсы 📣
21 февраля 11:00 по мск Александр Поломодов: Как на самом деле готовиться к System Design интервью
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками — https://system-design.space.
Мы обсудим:
• Почему книга не лучший…
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками — https://system-design.space.
Мы обсудим:
• Почему книга не лучший…
👍18❤11🔥6
Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026 (Рубрика #Architecture)
Интересное видео Kevlin Henney, где он выступает евангелистом монолитов, модульных монолитов:) Если сокращать, то он говорит, что проблема была не в монолитах, а в запутанных зависимостях и размытых границах. Союственно, микросервисы не лечат плохую декомпозицию. Но они просто делают ошибки дороже (сеть, консистентность, наблюдаемость, эксплуатация). Забавно, что свой первый монолит в Т-Банке я начал пилить как раз для того, чтобы довести эту стоимость до предела и перейти Рубикон (первая бекенд система, что мне досталась была сделана фронтедерами для фронтендеров и напоминала лапшу - по-другому выставить границы было нельзя).Но если возвращаться к рассказу Кевлина, то его совет в том, чтобы начинать с хорошо структурированного модульного монолита → и только потом (если есть устойчивые драйверы) выделяйте сервисы.
Отдельно мне понравилась история вокруг эволюции подходов, так как я сам люблю так выстраивать сторителлинг для своих докладов
- 1972 - Дэвид Пэрнас: критерии декомпозиции + information hiding (прячем то, что часто меняется)
- 1974 - Лисков и Зиллс: abstract data types (ADT), работа с абстракциями данных
- 1997 - Foote & Yoder: антипаттерн Big Ball of Mud (система "уползает" в комок без дисциплины)
- 2014 - Fowler/Lewis: микросервисы как набор independently deployable сервисов (а не "мелкие модули по сети")
- 2014+ - Simon Brown: предупреждение про distributed big ball of mud
Если говорить про инсайты, то они примерно такие
🧩 Модульность - свойство кода и зависимостей, а не инфраструктуры
Если внутри одного процесса вы не удерживаете границы, микросервисы не спасут - они просто добавят частичные отказы и сложность диагностики.
🕸 Архитектура проявляется в зависимостях сильнее, чем в диаграммах
Значит архитектуру можно (и нужно) делать проверяемой: правила → CI → "ломаем билд" на нарушениях.
🧩 “Монолит” становится проблемой, когда он превращается в tangled monolith
То есть не "один деплой" плохо, а переплетённость (циклы, обход границ, случайные импорты, нарушение слоёв).
🤑 Микросервисы - это инвестиция (техническая + организационная).
Они оправданы, когда реально нужно независимо деплоить, изолировать изменения, масштабировать по частям, разводить ответственность команд.
Если драйверов нет - вы покупаете overhead без выигрыша.
Для разработчиков следуют такие практические выводы
- Цель: сделать “границы” реальными, а не декоративными
Модуль = единица эволюции, а не папка. Есть публичный API, есть скрытая внутрянка, есть запреты на “обход”.
- Направление зависимостей важнее названий слоёв
Следите за циклами, “обратными” ссылками, протеканием инфраструктуры в домен.
Для технических руководителей следуют такие практические выводы
Архитектурные ярлыки не заменяют управления границами. Если мотивация “давайте микросервисы, чтобы код разделился сам” - это красный флаг.
Сначала: границы, ownership, правила, ревью‑политики, архитектурные тесты. Микросервисы по определению увеличивают:
- Число deploy‑единиц
- Количество коммуникаций
- Требования к CI/CD, observability, security, data contracts
Стратегия, которая обычно работает лучше:
- Modular monolith - дефолт
- Microservices - осознанная инвестиция при устойчивых драйверах
P.S.
Как обычно, расширенная версия есть на system-design.space.
#Architecture #Software #DistributedSystems #Engineering #Management
Интересное видео Kevlin Henney, где он выступает евангелистом монолитов, модульных монолитов:) Если сокращать, то он говорит, что проблема была не в монолитах, а в запутанных зависимостях и размытых границах. Союственно, микросервисы не лечат плохую декомпозицию. Но они просто делают ошибки дороже (сеть, консистентность, наблюдаемость, эксплуатация). Забавно, что свой первый монолит в Т-Банке я начал пилить как раз для того, чтобы довести эту стоимость до предела и перейти Рубикон (первая бекенд система, что мне досталась была сделана фронтедерами для фронтендеров и напоминала лапшу - по-другому выставить границы было нельзя).Но если возвращаться к рассказу Кевлина, то его совет в том, чтобы начинать с хорошо структурированного модульного монолита → и только потом (если есть устойчивые драйверы) выделяйте сервисы.
Отдельно мне понравилась история вокруг эволюции подходов, так как я сам люблю так выстраивать сторителлинг для своих докладов
- 1972 - Дэвид Пэрнас: критерии декомпозиции + information hiding (прячем то, что часто меняется)
- 1974 - Лисков и Зиллс: abstract data types (ADT), работа с абстракциями данных
- 1997 - Foote & Yoder: антипаттерн Big Ball of Mud (система "уползает" в комок без дисциплины)
- 2014 - Fowler/Lewis: микросервисы как набор independently deployable сервисов (а не "мелкие модули по сети")
- 2014+ - Simon Brown: предупреждение про distributed big ball of mud
Если говорить про инсайты, то они примерно такие
🧩 Модульность - свойство кода и зависимостей, а не инфраструктуры
Если внутри одного процесса вы не удерживаете границы, микросервисы не спасут - они просто добавят частичные отказы и сложность диагностики.
🕸 Архитектура проявляется в зависимостях сильнее, чем в диаграммах
Значит архитектуру можно (и нужно) делать проверяемой: правила → CI → "ломаем билд" на нарушениях.
То есть не "один деплой" плохо, а переплетённость (циклы, обход границ, случайные импорты, нарушение слоёв).
Они оправданы, когда реально нужно независимо деплоить, изолировать изменения, масштабировать по частям, разводить ответственность команд.
Если драйверов нет - вы покупаете overhead без выигрыша.
Для разработчиков следуют такие практические выводы
- Цель: сделать “границы” реальными, а не декоративными
Модуль = единица эволюции, а не папка. Есть публичный API, есть скрытая внутрянка, есть запреты на “обход”.
- Направление зависимостей важнее названий слоёв
Следите за циклами, “обратными” ссылками, протеканием инфраструктуры в домен.
Для технических руководителей следуют такие практические выводы
Архитектурные ярлыки не заменяют управления границами. Если мотивация “давайте микросервисы, чтобы код разделился сам” - это красный флаг.
Сначала: границы, ownership, правила, ревью‑политики, архитектурные тесты. Микросервисы по определению увеличивают:
- Число deploy‑единиц
- Количество коммуникаций
- Требования к CI/CD, observability, security, data contracts
Стратегия, которая обычно работает лучше:
- Modular monolith - дефолт
- Microservices - осознанная инвестиция при устойчивых драйверах
P.S.
Как обычно, расширенная версия есть на system-design.space.
#Architecture #Software #DistributedSystems #Engineering #Management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Modular Monoliths and Other Facepalms - Kevlin Henney - NDC London 2026
This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndclondon.com/
Subscribe to our YouTube channel and learn…
Attend the next NDC conference near you:
https://ndcconferences.com
https://ndclondon.com/
Subscribe to our YouTube channel and learn…
🔥21❤11💯5👍3
Дискуссия с Гришей Скобелевым про подготовку к 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
На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к 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
YouTube
Александр Поломодов: Как на самом деле готовиться к System Design интервью
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками - https://system-design.space.
Мы обсудим:
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты…
Мы обсудим:
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты…
1❤16🔥12👍8