Высоконагруженная архитектура
О стриме развития
Программа стрима
Всё необходимое для глубокого погружения в тему
Мастер-класс «Детские болезни доменных платформ: архитектурные ошибки, которые дорого чинить»
Кажется, что если платформа живет внутри BigTech, то там уже все давно правильно спроектировано, обдумано и выстрадано. Спойлер: нет. Боли есть всегда. В любой доменной платформе. Если это не BigTech, а стартап — боли там тоже есть, просто о них еще не знают. А потом мы все дружно и героически их чиним. И периодически сами же снова создаем — потому что никто из нас не идеален, особенно когда домен еще не прожит и времени на «сначала подумать» традиционно нет.
Этот разговор — про повторяющиеся архитектурные ошибки в доменных платформах. Не про инфраструктуру. Про те самые решения, которые сначала «ну пока так», а на этапе роста внезапно становятся очень дорогими.
Мы возьмем четыре платформенных домена, которые довольно часто одновременно существуют: — FinTech — Compliance — заказы и корзина в e-commerce — каталог и витрины и посмотрим на них как на одноранговые системы.
Потому что самое интересное — не в различиях. Самое интересное — в том, насколько одинаково они ломаются.
Это выступление не случайно в секции «Непривычные рамки». Это пере-доклад и недо-мастер-класс. Слушать и кивать не получится — придется думать, смотреть в схемы, искать, где именно спрятана проблема, и обсуждать, что с ней происходит при росте.
Я не буду рассказывать, как правильно. Мне гораздо интереснее показать, как обычно получается — даже у очень опытных команд — и почему это потом так больно чинить.
Главный вывод, к которому мы попробуем прийти вместе: неважно, в каком домене вы работаете. Если это платформенный домен, принципы их устройства и паттерны их поломок — сквозные. И если начинаешь их видеть, то начинаешь узнавать их везде.
Это разговор для тех, кто хотя бы раз приходил в новую компанию, смотрел на платформу и думал: «О, опять ОНО!».
Поиск без права на ошибку: мультимодальный RAG для чертежей и ГОСТов на одной Н100
В инженерии классический RAG не работает: семантический поиск легко путает допуски («0.02» вместо «0.012» на чертеже), а модели не видят топологию изделия (Болт ➝ Насос ➝ Двигатель). В докладе я разберу архитектуру CosmoSphere — гибридную систему поиска в закрытом контуре. Вы узнаете: Ядро: Как мультимодальная Nemotron-3-Omni-30B (Mamba+MoE) нативно совмещает чтение ГОСТов и сложный OCR чертежей без внешней каскадной обработки. Память: Скрещивание графовой базы FalkorDB и Qdrant для «триангуляционного поиска» (подъем точности с 60% до 94%, галлюцинации <2%). Инференс: Как уложить мультимодальный конвейер, обход графа и LLM-ризонинг в 80GB VRAM с помощью TensorRT-LLM и Triton без падений по OOM. Чистота: Сборка SOTA-стека из компонентов, доступных для Enterprise-контура в 2026 году.
Игра «System Design»
Архитектурное соревнование надо? Викторина по System Design и Архитектуре в live режиме! Будет яростный челендж по протоколам, архитектуре, паттернам и антипаттернам! А также по истории IT! Участники пройдут заранее отборочный этап на канале system_design_world. Записывайтесь! Сильнейшие ТОП-4 выйдут в финал уже на самой конференции! Где покажут чьи архитектурные мозги оказались сильнее! Окунитесь в мир System Design, участвуйте и болейте за своего финалиста!
Почему вам (скорее всего) не нужен локальный LLM-инференс
Мы строим платформу инференса и обычно пропагандируем идею "локальные LLM в продакшн". Но для средних и малых компаний рекомендация часто будет противоположная: не надо начинать с покупки GPU. В докладе покажу, где именно ломается экономика локального инференса и почему "поставим vLLM на свою карту" не равно "получим дешёвый продакшн-сервис".
Разбор будет через TCO. RTX 5090 можно арендовать за 50-90 тыс. рублей в месяц или купить за 300-500 тыс., но железо — только первая строка затрат. Дальше появляются ДЦ, электричество, охлаждение, сеть, мониторинг, деплой, кусочек или полный DevOps на поддержку и несколько человеко-месяцев на запуск. Даже если модель даёт хорошие tok/s в бенчмарке, карта ночью простаивает, днём упирается в потолок, а среднемесячная загрузка редко похожа на провайдерские 50-70%.
В конце разберём исключения: ИБ или регуляторика; GPU-парк в наследство от прошлого проекта; CAPEX, который проще защитить, чем OPEX; подозрительно постоянная нагрузка/training, под которую железо можно занять почти круглосуточно. В остальных случаях сначала стоит смотреть на API/OpenRouter, отечественные сервисы с оплатой по токенам или аренду GPU на короткий тест.
Реализация высокопроизводительной распределенной службы каталогов на Go и Badger DB
Служба каталогов является одним из ключевых компонентов корпоративной инфраструктуры и служит основой для реализации механизмов идентификации, аутентификации и управления доступом. Требования к производительности, масштабируемости и доступности приводят к построению распределённой архитектуры, в которой необходимо обеспечивать согласованность данных и координацию работы между узлами.
В рамках доклада рассматриваются следующие вопросы:
• построение распределённой архитектуры:
компромиссы распределённых систем (CAP), мультимастер-репликация, механизмы HWM/UTD, организация Pull-модели синхронизации, совместимость версий и обеспечение репликации при поэтапном обновлении системы;
• построение высокопроизводительного хранилища службы каталогов на основе BadgerDB:
реализация механизмов хранения, поиска и индексирования данных в KV-хранилище, организация иерархической модели данных, развитие поискового механизма и индексных структур.
Безопасность AI-агентов: векторы угроз и механизмы защиты
На реальных примерах шаг за шагом покажу типовые виды защиты AI-агентов и их уязвимости с точки зрения пентестера. Поделюсь и тем, что можно сделать во время разработки и на стадии поддержки, чтобы уменьшить шансы злоумышленников.
Пройдем путь от незащищенного агента к укрепленному, с примерами атак и фиксов: обход логики системных промптов с примерами из контестов и багбаунти, обходы ML guardrails с помощью сдвигов текста, шифрования ответов, смены языка и др. LLM guardrails через подбор состязательных суффиксов/префиксов, кейсы из Web3 (например, атака на автономных агентов с переводом активов), Telegram/Discord/Twitter агентов и мультиагентов
Практическая ценность: - Алгоритм аудита для своих LLM-агентов: как выявить уязвимости вроде prompt-injection или supply chain атак. - Шаблоны защит: опенсорсные инструменты (Ml Guardrails, Llama Guard, выбран за эффективность в блокировке 99.997% jailbreaks по тестам на 300k промптах). - Ссылки на таксономию уязвимостей промптов и сравнение моделей от нас (из исследования апрель 2025), и от Pangea (август 2025) - Ссылки на OWASP Top-10 LLM, AI agents, MITRE и предлагаемые ими схемы защиты
Как колоночное хранилище может помочь legacy?
В старых нагруженных корпоративных проектах часто можно встретить активное использование временных таблиц в СУБД. Нередко подобные решения оказываются очень чувствительными к росту объема поступающих в систему данных.
Чтобы оживить один из таких проектов без его модернизации мы воспользовались одним из ключевых преимуществ колоночных хранилищ и применили его к этому "проблемному" паттерну.
Вынос функционала из монолита
Бывает, что "распилить" монолит не хватает времени и ресурсов. Но есть критичный функционал, который необходимо вынести. В рамках мастер-класса решим задачу выноса сервиса мастер-баланса из монолитной банковской системы. По ходу, как всегда, изобретем несколько паттернов, обсудим плюсы и минусы различных технологических решений, погрузимся в особенности работы баз данных и шардирование.