🎥 Запускаем серию архитектурных стримов, основанных на реальных кейсах. Сегодня первая встреча!

🗓 18 декабря
⏰ 20:00 GMT+3

На первом стриме разберём настоящий RFP:
платформу автоматизированной обработки RFQ-документов с ИИ-модерацией, чат-ботом и BI-аналитикой.

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

👤 Ведущий: Андрей Якушин, Solution Architect и Engineering Manager с 18+ лет в IT (архитектура enterprise-систем, финансы, здравоохранение, cloud: AWS / Azure / GCP).

Это только начало серии. Подключайтесь 🚀

Почему говнокод ≠ техдолг, что это на самом деле, и как с ним работать

Технический долг – это инструмент для ускорения time-to-market, а не индульгенция на низкую квалификацию или лень разработчиков.

🚫 Плохой код – это не техдолг

Давайте сразу разделим понятия. Беспорядок в коде – это не долг. Если разработчики пишут всё в одном файле, называют переменные как попало или не могут связать два модуля – это просто плохо сделанная работа.

Техдолг – это осознанный компромисс. Это ситуация, когда вы сознательно делаете криво, понимая, что переделка этого решения будет стоить дешевле, чем делать идеально прямо сейчас. У техдолга, как у финансового кредита, есть тело и проценты.

У говнокода процентов нет – он просто тормозит вас с первой секунды.

📉 Гипотеза выносливости (Design Stamina Hypothesis)

Метафора техдолга часто используется ошибочно:

Мы сейчас наговнокодим, чтобы зарелизить быстрее

Это работает, только если вы находитесь ниже Design Payoff Line (Линии окупаемости дизайна).

Суть гипотезы Мартина Фаулера проста:

🔸 Проект без дизайна стартует быстро, но график продуктивности резко падает вниз по мере накопления энтропии

🔸 Проект с хорошим дизайном стартует медленнее, но сохраняет стабильную скорость развития

Точка пересечения этих линий – Design Payoff Line.

Опасность в том, что многие считают, будто эта линия находится где-то через месяцы разработки. На практике, в современных реалиях, эта точка наступает через несколько недель.

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

🧩 Квадрант техдолга: диагностика команды

Чтобы понять, как лечить проект, нужно понять природу вашего долга. Мартин Фаулер делит его на 4 типа – Квадрант Техдолга.

🔹 Неосознанный / Умышленный.

У нас нет времени на проектирование, пилим фичи

Суть: Команда осознает неоптимальность, но игнорирует анализ ради скорости. Это сметание мусора под ковер.

Решение: Единственный выход – смена инженерной культуры или самой команды. Здесь лечить код бесполезно, пока не вылечены процессы.

🔹 Осознанный / Умышленный.

Нам нужно зарелизить фичу к дедлайну, мы знаем, что это костыль, и у нас есть план, как его убрать

Суть: Классический, правильный техдолг. Быстрое решение для выхода на рынок.

Решение: Иметь четкий бэклог по возврату долга. Не позволяйте ему вырасти выше вашей способности его обслуживать.

🔹 Неосознанный / Неумышленный.

А что такое слоистая архитектура?

Суть: Мы делаем фигню, потому что просто не знаем, как делать правильно. Команда просто неквалифицирована для текущих задач.

Решение: Обучение. Менторство, курсы, pair programming.

🔹 Осознанный / Неумышленный.

Теперь мы поняли, как надо было делать

Суть: Неизбежный долг. Технологии меняются, требования уточняются. То, что год назад было хорошим решением, сегодня стало легаси.

Решение: Ретроспективы. Анализируйте, почему архитектура устарела, и внедряйте рефакторинг как постоянный процесс.

🛠 Best Practices: как не обанкротиться

Техдолг становится проблемой только тогда, когда вы теряете над ним контроль.

🔸 Держитесь ниже Design Payoff Line. Если вы не стартап, который умрет через неделю без релиза, инвестиции в дизайн окупаются почти мгновенно. Отказ от тестов и архитектуры ради скорости – иллюзия.

🔸 Фиксируйте долг. Если вы идете на сделку с совестью (Осознанный/Умышленный долг), создавайте тикет в Jira сразу же. Нет тикета – нет долга, есть просто забытый говнокод.

🔸 Обучайте команду. Если долг растет из-за недостатка скиллов (Неумышленный), никакие процессы не помогут. Учите людей или нанимайте техлидов, которые подтянут уровень.

🔸 Регулярная выплата процентов. Выделяйте 10–20% времени в спринте на рефакторинг. Это обслуживание кредита, которое позволяет телу долга не раздавить вашу производительность.

Здесь вы можете почитать о техдолге подробнее и получить Mind-map «Эффективное управление техническим долгом»

Каким был 2025 год для Hard&Soft Skills?

Самое время оглянуться назад и подвести итоги насыщенного года:

🎓 Образовательный трек в цифрах

120 инженеров успешно прошли обучение на наших программах. Мы провели 5 курсов:

🔸 2 больших потока курса [Технический лидер]. Кстати, в феврале стартует уже юбилейный 20-й поток, записывайтесь на консультацию!
🔸 2 курса Solution Architect in the Wild.
🔸 1 поток программы из Middle в Senior.

Но самое ценное — это не сухая статистика, а качественный рост наших выпускников.

Вот как они описывают результаты:

Я выбирал между сертификацией TOGAF, институтом SAE и курсом "Технический лидер". Взвесив всё, я понял, что по фундаментальности и прикладной пользе для реальной архитектурной работы курс "Технический лидер" подходит идеально.

Курс учит не просто рисовать "красивые схемы" или заучивать шаблоны для интервью, а именно мыслить как архитектор.

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

За эти инсайты и рост благодарим наших преподавателей — Антона Дворникова, Светлану Семенову, и, конечно, Павла Вейника!

🌍 Сообщество

В 2025 году мы провели 52 ивента!

🗣 Организовали 9 Архитектурных трепов и 27 Конклавов.
⚙️ Провели 5 Круглых столов и 3 Software craftsmanship митапа.
🏠 Впервые полноценно встретились оффлайн — и сразу дважды: в Батуми и в Алматы! Благодарим наших партнеров и, конечно, всех, кто пришел – без вас не было бы так круто!

Огромное спасибо ведущим, модераторам и участникам круглых столов:

Юрий Морозов, Павел Вейник, Антон Дворников, Алексей Лобан, Вадим Гацура, Александр Орлов, Илья Кремнёв, Евгений Кошелев, Виктория Телюк, Денис Филипкин, Максим Симоненко, Александр Кохно, Никита Щетько, Владимир Хростицкий, Peter Hanzo, Данида Поддубный, Анастасия Бакулова, Игорь Круглов, Ильшат Назаргулов, Ринат Тлеукулов, Марина Хомич, Артём Головачёв, Александр Маркевич, Никита Старостин, Ирина Асон, Максим Аршинов, Евгений Соколов, Андрей Якушин, Alex Pshul, Максим Сальников, Елизавета Булыгина.

2025 получился насыщенным и ярким. Спасибо за то, что помогли нам сделать его таким! Обещаем в следующем году не сбавлять темп. С наступающими праздниками!

Почему вы застряли на уровне Senior и как пробить стеклянный потолок?

🧠 Кто такой Senior на самом деле

Senior – это не “разработчик с 5 годами опыта”, а автономная боевая единица. Это инженер, который конвертирует бизнес-задачи в работающие решения с предсказуемым качеством и сроками.

Для бизнеса Senior – это точка безубыточности. Его не нужно микроменеджить, он сам видит риски и закрывает их.

📉 Смена парадигмы: почему старые методы не работают

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

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

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

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

🚧 Чего не хватает для перехода в Staff/Principal/Lead

Главная причина застревания – попытка решать проблемы нового уровня старыми инструментами. Сеньоры часто пытаются закодить организационные или архитектурные проблемы, вместо того чтобы влиять на процессы.

Для роста необходимо понимание фундаментальных принципов, широкий кругозор и умение находить контакт с разными людьми в компании:

🔹 Фундамент: детали устройства сети, архитектуры компьютера и памяти – это принципы, которые не меняются со сменой версий языка.

🔹 Распределенные системы: знание теоремы CAP, паттернов проектирования, работы с нагрузкой и консистентностью данных.

🔹 Умение находить trade-offs: архитектор не ищет идеальное решение, он выбирает наименее плохое, балансируя между latency, throughput и надежностью.

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

🔹 Коммуникации: Умение продавать технические решения бизнесу и договариваться с другими командами. Техническая правота ничего не стоит, если вы не можете ее аргументировать на языке денег и рисков.

🛋 Зачем расти дальше, если и так комфортно?

Рост выше Senior необходим, если:

🔸 Вы уперлись в финансовый потолок рынка для Individual Contributor.

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

🔸 Вы хотите масштабировать свою экспертизу: ваш код работает в одном месте, а ваши архитектурные решения работают во всей компании.

🗺 Где взять карту для дальнейшего пути

Навыки уровня Tech Lead или Architect редко приобретаются в повседневной текучке. Они требуют смены мышления и общения с теми, кто этот путь уже прошел.

🗓 Митап «Технический Лидер»

Когда: 20 января в 19:00 (GMT+3)

Разберем реальные кейсы перехода на уровень выше senior, обсудим диаграмму навыков техлида и тренды рынка в 2026 году.

👉 Регистрируйтесь по ссылке

📊 Выбираем архитектуру данных
Митап для тех, кто работает с данными, строит продуктовые системы и хочет мыслить на уровне архитектуры.

📆 13 января, 20.00 GMT+3

О чём поговорим:

1️⃣ Что такое архитектура данных?
Чем она отличается от привычной архитектуры ПО и почему без неё сегодня не живёт ни один серьёзный продукт.

2️⃣ Типичные задачи и требования.
С какими проблемами мы сталкиваемся, когда речь идёт о данных, масштабировании, скорости, надёжности и интеграциях?

3️⃣ Как выбрать архитектурный подход.
Разберём ключевые модели и паттерны, их плюсы и ограничения, что работает в каких сценариях и почему.

🎤 Спикер: Илья Гордеенко, Lead Data & Software Architect, более 10 лет опыта.

Регистрация

Закон Конвея: Почему структура вашей команды диктует архитектуру кода

📜 Закон Конвея: база

Любая организация, проектирующая систему, неизбежно создаст дизайн, который копирует коммуникационную структуру этой организации.

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

🧬 Механизмы трансляции: социальная физика кода

Оргструктура влияет на код через транзакционные издержки. Если команды неделю согласовывают контракт API, разработчики инстинктивно выбирают архитектурные паттерны, минимизирующие это общение (например, дублирование логики или создание толстых кэширующих слоев).

Границы модулей формируются зонами Ownership и процессами код-ревью. Если для изменения функции нужно одобрение лида соседней команды, вы либо вынесете эту функцию в библиотеку, либо обернете её в микросервис, чтобы деплоить независимо.

CI/CD пайплайны и частота релизов цементируют архитектуру: отдельный репозиторий = отдельный деплой = жесткая граница.

⚖️ Трейд-оффы: ускорение vs изоляция

Зеркальность архитектуры и структуры полезна, когда цель – High Velocity внутри вертикальных доменов. Кросс-функциональная команда, владеющая всем стеком (от UI до БД) в рамках одного бизнес-контекста, движется максимально быстро, так как издержки коммуникации минимальны.

Однако это становится барьером при масштабировании. Если архитектура строго поделена по отделам, реализация сквозной фичи превращается в ад согласований. В таких случаях нужно сознательно "размывать" границы (Shared Kernel, InnerSource), жертвуя изоляцией ради связности продукта.

🔄 Обратный маневр Конвея

Не пытайтесь натянуть чистую архитектуру на старую бюрократию. Сначала спроектируйте команды:

🔹 Stream-aligned teams: Формируйте команды вокруг потока ценности (User Journey), а не вокруг слоев (Frontend/Backend/DB). Так сервисы будут ориентированы на бизнес-домены.

🔹 Platform teams: Выделите инфраструктурную сложность в платформу (X-as-a-Service). Это создаст четкий API-раздел и снизит когнитивную нагрузку на продуктовые команды.

🔹 Interaction Modes: Фиксируйте типы взаимодействия (Team Topologies). Если одна команда зависит от другой, это должен быть либо сервис (API-контракт), либо коллаборация (совместный код), но не "просьбы в личку".

📊 Сигналы и метрики дисбаланса

Как понять, что структура команды ломает архитектуру (или наоборот)? Смотрите в git и трекер:

🔸 Logical Coupling vs Org Distance: Файлы часто меняются вместе в одном коммите, но принадлежат разным командам? У вас архитектурный разрыв.

🔸 Cross-team PR ratio: Если пулл-реквесты часто требуют аппрува внешних команд – значит границы абстракций протекают.

🔸 Change Failure Rate на стыках: Инциденты часто возникают на границах API? Значит, коммуникация о контрактах слабее, чем техническая связность сервисов.

🔸 Conway's Law Mismatch: Сравните граф вызовов сервисов с графом общения в Slack/Jira. Если сервис А вызывает сервис Б, но команды не общаются – ждите проблем с обратной совместимостью.

🛠 Тактики безопасной миграции

Изменять архитектуру через реорганизацию людей нужно осторожно. Используйте проверенные паттерны декомпозиции:

🔹 Анти-коррупционные слои (ACL): Если вы не можете изменить легаси-команду, изолируйте их систему адаптером, который транслирует их модель данных в вашу "чистую" модель. Это позволяет вашей архитектуре эволюционировать независимо от их оргструктуры.

🔹 Strangler Fig Pattern: Создайте новую команду под новый домен. Позвольте им перехватывать трафик по кусочкам, постепенно "удушая" старую функциональность. Здесь архитектурная миграция следует за перераспределением ответственности людей.

🔹 Временные Task Forces: Для реализации сложных сквозных изменений (например, смена ID провайдера) создавайте временные команды с полномочиями коммитить в любые репозитории.

После завершения работы команда распускается, а владение кодом возвращается в стримы. Риск здесь – потеря знаний, поэтому документация (ADR) критична.

💳 Inside a Payment Gateway или почему платёжный мир всё ещё держится на монолитах

Сегодня вечером разбираем платёжные системы изнутри:

– Payments 101: что такое платёжный домен и из чего он состоит
– Как требования enterprise-мерчантов формируют архитектуру gateway
– Почему решения, принятые десятилетия назад, продолжают работать
– Как бюджет, партнёрства и инфраструктура влияют на архитектурные подходы
– И главное: почему старые монолиты всё ещё выигрывают

🎙 Спикер: Илья Чекун, backend-инженер из Швейцарии, эксперт по платёжным системам и альтернативным методам оплаты.

🗓 15 января 20:00 GMT+3

Регистрация

System Design vs Architecture: В чем разница и почему их путают?

🧶 Что есть что и где граница

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

System design – это то, как именно система все это делает: какие конкретно используются БД, кэши и библиотеки, какие паттерны проектирования применяются, чтобы удовлетворить нефункциональные требования.

То есть, system design – составляющая часть архитектуры.

Граница плавающая. В стартапе на стадии MVP выбор PostgreSQL вместо MongoDB – это архитектурное решение, определяющее скорость разработки и гибкость схемы данных. В enterprise, где уже есть платформа данных и инфраструктура, подключение очередной базы – это рутинная задача дизайна.

🎭 Кто за что отвечает: Архитектор vs Техлид vs Senior

В идеальном мире разграничение выглядит так:

Архитектор владеет нефункциональными требованиями (NFR) верхнего уровня: Availability, Modifiability, Security. Он принимает решение пожертвовать strong consistency ради доступности в распределенной системе.

Техлид транслирует архитектуру в код. Он решает, как именно реализовать eventual consistency (Saga или 2PC), и балансирует технический долг со сроками.

Senior-разработчик отвечает за локальный дизайн модуля. Он выбирает стратегию блокировок в базе или алгоритм сжатия данных.

В реальности, особенно в небольших командах, все эти роли могут лечь на одного сеньора.

Конфликт возникает, когда локальная оптимизация (Senior хочет сэкономить байты через Protobuf) ломает глобальный принцип (Архитектор требует JSON для читаемости и debuggability). Здесь помогает матрица RACI, где четко прописано, кто Accountable за межсервисные контракты.

⚖️ Метрики успеха

Оценивать архитектуру метриками кода – ошибка. Хороший дизайн может привести к отличной производительности, но сделать систему абсолютно негибкой.

🔸 Метрики архитектуры:

Evolutionary Cost: Сколько человеко-часов стоит добавление новой сущности?

DORA Metrics: Показывают эффективность процессов, заданных архитектурой:

1. Deployment Frequency – как часто катим
2. Lead Time for Changes – время от коммита до прода
3. Change Failure Rate – процент релизов, требующих фикса
4. Time to Restore Service – время восстановления после сбоя

Total Cost of Ownership: Стоимость инфраструктуры + лицензии + стоимость поддержки. Если архитектура требует x3 ресурсов облака для простых задач – это архитектурный провал.

🔸 Метрики дизайна:

Operational: Throughput, P99 Latency, Error Rate.

Code Quality: Тестовое покрытие, цикломатическая сложность, время сборки.

Fan-in / Fan-out
1. Fan-in: сколько модулей зависят от текущего
2. Fan-out: от скольких модулей зависит текущий

Архитектура считается успешной, если при росте нагрузки (метрика дизайна) стоимость изменений (метрика архитектуры) растет нелинейно медленно.

🔍 Ошибка восприятия: Дизайн или Архитектура?

Часто плохой архитектурой называют просто отсутствие контрактов или документации.

Если вам приходится править 5 микросервисов, чтобы добавить одно поле на фронтенде – это ошибка архитектуры.

Если же сервис упал из-за out of memory при обработке большого файла – это ошибка дизайна (неправильная работа с потоками), даже если она привела к отказу всей системы.

🛡 Практики эволюции

Чтобы не переписывать систему каждые два года, нужно внедрять инструменты, фиксирующие договоренности на уровне кода и процессов.

🔹 ADR: Не просто "мы выбрали Kafka", а почему, какие были альтернативы и с чем придется жить. Это снимает вопросы "кто это придумал?" через год.

🔹 Consumer-Driven Contracts: Тесты, которые гарантируют, что изменения в дизайне продюсера не сломают архитектурный контракт с консьюмером.

🔹 Fitness Functions в CI/CD: Автоматические проверки архитектурных правил. "Слой контроллеров не должен ходить в базу напрямую". Если правило нарушено – пайплайн падает.

🔹 Версионирование API и Tolerant Reader: Принципы дизайна, которые спасают архитектуру от жесткой связности при эволюции схем данных.

Quality Attributes и как их измерять

🎯 Бизнес-импакт и карта рисков

Каждый атрибут качества должен быть привязан к конкретному бизнес-риску.

Если падает Scalability, мы теряем не RPS, а долю рынка во время пиковых распродаж.

Если падает Maintainability, растет Time-to-Market, и конкуренты нас обгоняют.

Для эффективного измерения разделите метрики на два класса:

Lagging (Запаздывающие): SLA, MTTR, стоимость инцидента. Они говорят, что уже сломалось и сколько денег потеряно.

Leading (Опережающие): Cyclomatic Complexity, Code Churn, время сборки, покрытие тестами. Они предсказывают, где рванет через месяц. Рост сложности кода сегодня — это гарантированный рост MTTR завтра.

🧩 Композитные метрики

Одиночная метрика (например, Average Latency) лжет. Она сглаживает пики и скрывает "длинный хвост", где страдают пользователи. Чтобы видеть реальную картину, стройте композитные индексы здоровья системы, объединяя сигналы разной природы.

Например, для атрибута Reliability (Надежность) недостаточно просто считать 200 OK.

Композит должен включать:

🔸 Success Rate: Процент успешных бизнес-транзакций (а не просто HTTP-запросов).
🔸 Latency Distribution: 99-й перцентиль задержки (p99) — именно здесь живут ваши самые требовательные пользователи.
🔸 Freshness: Возраст данных, отдаваемых пользователю (актуально для read-heavy систем с кэшированием).
🔸 Durability: Гарантия того, что принятые данные записаны на диск и реплицированы (lag репликации).

Нормализуйте эти показатели по текущей нагрузке и окнам релизов. Резкий скачок ошибок сразу после деплоя и плавный рост ошибок при неизменном коде — это сигналы для разных команд (Dev vs Ops).

📉 Шум vs. Реальная деградация

Алерт на каждый спайк CPU — верный путь к выгоранию on-call инженера. Ваша задача — отделить случайный шум от системного деградационного тренда.

Используйте SLO Burn Rate вместо мгновенных значений. Это скорость, с которой расходуется ваш "бюджет на ошибки". Если за час мы сожгли 2% месячного бюджета ошибок — это инцидент. Если 0.01% — это шум.

Для детекции трендов применяйте статистические методы:

Change Point Detection: Алгоритмы (например, CUSUM), которые находят момент смещения среднего значения или дисперсии. Это позволяет увидеть деградацию производительности после релиза на 5%, которую глаз на графике не заметит.

A/B и Canary: Валидируйте гипотезы через сравнение когорт. Если на новой версии latency p99 выше на 10ms с p-value < 0.05 — это не флуктуация, а повод для отката.

🔭 Доверие к данным

Метрики бесполезны, если им нельзя доверять. Плохая телеметрия хуже ее отсутствия, так как ведет к неправильным архитектурным решениям. Проблема часто кроется в потере контекста в распределенных системах.

Чтобы данные были action-oriented:

🔹 Семантика ошибок: Разделяйте ошибки инфраструктуры (502/504) и ошибки бизнес-логики (4xx или “недостаточно средств”). Это разные атрибуты качества (Availability vs Usability).
🔹 High-Cardinality Tags: Обогащайте метрики tenant_id, версией клиента, feature-флагом. Это позволяет мгновенно локализовать проблему (тормозит только у iOS-клиентов в Европе).
🔹 Умный семплинг: Вместо random sampling используйте tail-based sampling. Сохраняйте 1% успешных трейсов и 100% ошибочных или медленных. Это даст полную картину сбоев без перегрузки хранилища.

⚙️ От дашбордов к инженерным решениям

Измерение — не самоцель. Цикл должен замыкаться на действии. Переводите метрики QA в язык ROI для бизнеса.

Не просите время на рефакторинг. Покажите тренд:

За последние полгода Cyclomatic Complexity модуля Core выросла на 40%, что коррелирует с ростом MTTR с 2 до 8 часов. Мы теряем $X на каждом простое. Рефакторинг вернет MTTR к норме и окупится за 3 месяца.

Внедряйте Fitness Functions в CI/CD пайплайны. Если PR ухудшает метрику startup time на 50ms или снижает покрытие документацией, сборка должна падать.

Так атрибуты качества превращаются из абстрактного пожелания в жесткий инженерный контракт.

Архитектурный Трёп №132 уже завтра!

📅27 января, 20.00 GMT+3

Как менять технологическое направление, когда карьера уже сложилась

Поговорим честно про:
• что становится триггером для смены направления
• страх потери статуса, влияния и ощущения компетентности
• реальные стратегии перехода: pet-projects, внутренние трансферы, менторство, contribution, курсы
• и правда ли, что технологии вторичны, а инженерное мышление - главный transferable skill

🎙 Модератор: Анастасия Бакулова

👉 Регистрация

Я допиливаю программы курсов по AI, и у меня есть вопрос что вам больше интересно:
1. «Я все пропустил, что там происходит?»: от промптинга/рулов/скилов до последних трендов, системный взгляд на область AI. Разумеется, агенты, использование AI для кода и для процессов/документации, основы MCP, RAG и прочих аббревиатур, и конечно - когда и что использовать из существующих подходов/моделей/сред разработки. На выходе - человек, который спокойно ориентируется в текущем состоянии отрасли и в трендах, и который может заниматься «обычной» прикладной автоматизацией или другими проектами теперь и с помощью AI.
2. «Я разрабатываю агенты, делаю свои MCP, использую RAG»: архитектура агентов (оркестрация, долгосрочная память, chain of thought и др способы планирования действий), knowledge graphs, agentic RAG. MCP в глубину - управление состоянием внутри сервера MCP, security/auth, транспорты для удаленных агентов. Как не только разработать, но и поддерживать/документировать/управлять - LLMOps, observability, автоматическая оптимизация промптов. при интересе - и как/какие/для чего модели ставить on premise или в собственном облаке.
3. «Я - первый вайбкодер-единорог!»: все для быстрой разработки и валидации гипотез, для запуска своих проектов с помощью AI и существующих инструментов. TTM - наше все! скоростное написание кода, full-stack генерация приложений, инфраструктура из коробки, low code и no code инструменты, growith hacking и маркетинг, быстрое прототипирование мобильных приложений. Про инвестиции не будет ничего, но если что найдем способ помочь.
4. «Я участвую в разработке и улучшаю LLM»: почему перемножение матриц внутри LLM вдруг стало думать как люди(или лучше людей)? Архитектура LLM внтутри - токены, вектора слов, матрицы, механизм внимания, feed forward networks. Пространства смыслов и операции с ними, фантазия (probabilistic determinism vs галлюцинации) в LLM. Где именно модель думает, а где вспоминает факты (induction heads, sparse autoencoders, ablation). Тут вы узнаете почему модель не может считать (пальцы, буквы) и где возникает смысл. Для домашних заданий потребуется много оперативки.
5. «Не угадал, я напишу в чате что мне больше интересно.»
(Павел Вейник)

CAP и PACELC: Базовые законы, которые нельзя нарушить (даже если очень хочется)

🛡 CAP: Иллюзия выбора двух из трех

Многие трактуют теорему Брюера как меню в ресторане: "Выберите любые два пункта". Но для распределенной системы Partition Tolerance (P) – это не опция, а данность. Сети ненадежны: свитчи горят, GC-паузы останавливают ноды, пакеты теряются.

Когда происходит сетевое разделение (partition), вы теряете связь между узлами. В этот момент (и только в этот!) вы обязаны сделать жесткий выбор:

Отказаться от Availability (вернуть ошибку или тайм-аут), чтобы сохранить данные согласованными (CP).

Пожертвовать Consistency (отдать устаревшие данные), чтобы система продолжила отвечать (AP).

Попытка построить "CA-систему" в распределенной среде – это игнорирование физики сетей. Если вы утверждаете, что у вас CA, вы просто еще не столкнулись с разделением сети, которое сломает вашу линеаризуемость.

⚖️ PACELC: О чем молчит CAP в мирное время

CAP описывает поведение системы только во время сбоя в сети. Но системы работают в штатном режиме 99.9% времени. Здесь на сцену выходит расширение теоремы – PACELC.

Она формулируется так:

If P (Partition), then choose A (Availability) or C (Consistency).

Else (no Partition), choose L (Latency) or C (Consistency).

Это фундаментальный трейд-офф, который часто упускают: даже когда сеть работает идеально, вы не можете получить мгновенный отклик (low latency) и строгую согласованность одновременно. Репликация данных требует времени.

Хотите, чтобы все узлы всегда видели одни и те же данные? Платите за round-trip синхронизации (увеличиваем latency).

Хотите отвечать мгновенно? Читайте с локальной реплики, но рискуйте получить stale data (жертвуем consistency).

🎛 Градиент, а не переключатель: Tunable Consistency

Для Senior-инженера выбор базы данных – это не просто "Postgres vs Cassandra", а понимание моделей согласованности. Современные БД позволяют гибко настраивать этот баланс через кворумы (Quorums).

Формула $R + W > N$ (где N – фактора репликации, R – узлов для чтения, W – узлов для записи) – база, но дьявол в деталях:

🔹 Strong Consistency (CP / PC в терминах PACELC):
Требует $W = N$ или большинства (Quorum). Это алгоритмы консенсуса (Paxos, Raft). Примеры: CockroachDB, Etcd, Zookeeper.

Цена: Высокая latency на запись, невозможность записи при падении миноритариев.

🔹 Eventual Consistency (AP / EL):
Допускаем $R + W ≤ N$. Система "в конечном счете" станет согласованной. Примеры: Cassandra, DynamoDB (с дефолтными настройками), Riak.

Цена: Конфликты версий (Vector Clocks, LWW), риск потери данных при одновременной записи, сложность отладки.

🔹 Causal Consistency:

Золотая середина, которую часто упускают. Гарантирует, что операции, связанные причинно-следственной связью, видны в правильном порядке. Это слабее, чем линеаризуемость, но сильнее, чем eventual consistency, и не так сильно бьет по latency.

🧠 Consistency в CAP ≠ Consistency в ACID

Критически важное различие для техлида.

ACID Consistency: Переход базы данных из одного валидного состояния в другое с учетом бизнес-правил (инвариантов, constraints).

CAP Consistency: Это Linearizability (линеаризуемость). Если операция записи завершилась, любая последующая операция чтения (на любой ноде) должна вернуть новое значение. Это свойство системы, а не данных.

Ошибочное смешивание этих понятий ведет к архитектурным просчетам, когда от NoSQL базы ожидают соблюдения foreign keys только потому, что выбрали "CP-mode".

📚 Что почитать по теме

Daniel J. Abadi – "Consistency Tradeoffs in Modern Distributed Database System Design" (оригинальная статья по PACELC).

Martin Kleppmann – "Designing Data-Intensive Applications" (Главы 7, 8, 9 – обязательное чтение для любого сеньора).
Можно посмотреть обсуждение у нас на YouTube