Высоконагруженная архитектура

О стриме развития

Стримы развития — это срежиссированные тематические маршруты по конференции

Программа стрима

Всё необходимое для глубокого погружения в тему

22 июня, 10:30 - 12:30, Зал Розовый

Мастер-класс «Детские болезни доменных платформ: архитектурные ошибки, которые дорого чинить»

Кажется, что если платформа живет внутри BigTech, то там уже все давно правильно спроектировано, обдумано и выстрадано. Спойлер: нет. Боли есть всегда. В любой доменной платформе. Если это не BigTech, а стартап — боли там тоже есть, просто о них еще не знают. А потом мы все дружно и героически их чиним. И периодически сами же снова создаем — потому что никто из нас не идеален, особенно когда домен еще не прожит и времени на «сначала подумать» традиционно нет.

Этот разговор — про повторяющиеся архитектурные ошибки в доменных платформах. Не про инфраструктуру. Про те самые решения, которые сначала «ну пока так», а на этапе роста внезапно становятся очень дорогими.

Мы возьмем четыре платформенных домена, которые довольно часто одновременно существуют: — FinTech — Compliance — заказы и корзина в e-commerce — каталог и витрины и посмотрим на них как на одноранговые системы.

Потому что самое интересное — не в различиях. Самое интересное — в том, насколько одинаково они ломаются.

Это выступление не случайно в секции «Непривычные рамки». Это пере-доклад и недо-мастер-класс. Слушать и кивать не получится — придется думать, смотреть в схемы, искать, где именно спрятана проблема, и обсуждать, что с ней происходит при росте.

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

Главный вывод, к которому мы попробуем прийти вместе: неважно, в каком домене вы работаете. Если это платформенный домен, принципы их устройства и паттерны их поломок — сквозные. И если начинаешь их видеть, то начинаешь узнавать их везде.

Это разговор для тех, кто хотя бы раз приходил в новую компанию, смотрел на платформу и думал: «О, опять ОНО!».

Екатерина Лысенко

Екатерина Лысенко

Независимый эксперт

22 июня, 12:50 - 13:40, Зал Башня

Поиск без права на ошибку: мультимодальный 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 году.

Андрей Носов

Андрей Носов

Raft

22 июня, 15:20 - 17:20, Зал Синий

Игра «System Design»

Архитектурное соревнование надо? Викторина по System Design и Архитектуре в live режиме! Будет яростный челендж по протоколам, архитектуре, паттернам и антипаттернам! А также по истории IT! Участники пройдут заранее отборочный этап на канале system_design_world. Записывайтесь! Сильнейшие ТОП-4 выйдут в финал уже на самой конференции! Где покажут чьи архитектурные мозги оказались сильнее! Окунитесь в мир System Design, участвуйте и болейте за своего финалиста!

Владимир Невзоров

Владимир Невзоров

Servicepipe

23 июня, 10:00 - 10:50, Зал Башня

Почему вам (скорее всего) не нужен локальный LLM-инференс

Мы строим платформу инференса и обычно пропагандируем идею "локальные LLM в продакшн". Но для средних и малых компаний рекомендация часто будет противоположная: не надо начинать с покупки GPU. В докладе покажу, где именно ломается экономика локального инференса и почему "поставим vLLM на свою карту" не равно "получим дешёвый продакшн-сервис".

Разбор будет через TCO. RTX 5090 можно арендовать за 50-90 тыс. рублей в месяц или купить за 300-500 тыс., но железо — только первая строка затрат. Дальше появляются ДЦ, электричество, охлаждение, сеть, мониторинг, деплой, кусочек или полный DevOps на поддержку и несколько человеко-месяцев на запуск. Даже если модель даёт хорошие tok/s в бенчмарке, карта ночью простаивает, днём упирается в потолок, а среднемесячная загрузка редко похожа на провайдерские 50-70%.

В конце разберём исключения: ИБ или регуляторика; GPU-парк в наследство от прошлого проекта; CAPEX, который проще защитить, чем OPEX; подозрительно постоянная нагрузка/training, под которую железо можно занять почти круглосуточно. В остальных случаях сначала стоит смотреть на API/OpenRouter, отечественные сервисы с оплатой по токенам или аренду GPU на короткий тест.

Егор Андреев

Егор Андреев

Admindivision / Впрод

23 июня, 10:00 - 10:50, Зал Розовый

Реализация высокопроизводительной распределенной службы каталогов на Go и Badger DB

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

В рамках доклада рассматриваются следующие вопросы:

• построение распределённой архитектуры:
компромиссы распределённых систем (CAP), мультимастер-репликация, механизмы HWM/UTD, организация Pull-модели синхронизации, совместимость версий и обеспечение репликации при поэтапном обновлении системы;

• построение высокопроизводительного хранилища службы каталогов на основе BadgerDB:
реализация механизмов хранения, поиска и индексирования данных в KV-хранилище, организация иерархической модели данных, развитие поискового механизма и индексных структур.

Собир Абдуллаев

Собир Абдуллаев

Avanpost

23 июня, 11:10 - 12:00, Зал Розовый

Безопасность 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 и предлагаемые ими схемы защиты

Юрьева Радда

Юрьева Радда

Positive Technologies

23 июня, 12:20 - 13:10, Зал Розовый

Как колоночное хранилище может помочь legacy?

В старых нагруженных корпоративных проектах часто можно встретить активное использование временных таблиц в СУБД. Нередко подобные решения оказываются очень чувствительными к росту объема поступающих в систему данных.

Чтобы оживить один из таких проектов без его модернизации мы воспользовались одним из ключевых преимуществ колоночных хранилищ и применили его к этому "проблемному" паттерну.

Михаил Шишкин

Михаил Шишкин

ООО Газинформсервис

23 июня, 12:20 - 14:20, Зал Синий

Вынос функционала из монолита

Бывает, что "распилить" монолит не хватает времени и ресурсов. Но есть критичный функционал, который необходимо вынести. В рамках мастер-класса решим задачу выноса сервиса мастер-баланса из монолитной банковской системы. По ходу, как всегда, изобретем несколько паттернов, обсудим плюсы и минусы различных технологических решений, погрузимся в особенности работы баз данных и шардирование.

Алексей Лосев

Алексей Лосев

Wildberries & Russ