Архитектура типового контура платформы в двух слоях. Технологический: кластер, платформенные компоненты внутри него, внешние системы за периметром и технологические сервисы, которые всё это даёт приложениям. Прикладной: компоненты платформы по смысловым группам, вызовы между ними и зависимость каждого от технологических сервисов. Имена кластера, узлов, доменов и реестра заменены на примеры — конкретная инсталляция задаётся отдельным профилем контура.

Связи не нарисованы от руки, а выведены из манифестов развёртывания: переменных окружения, аннотаций и маршрутов. Исключения оговорены отдельно — внешние интеграции и смысловая группировка приложений заданы профилем, описания компонентов получены чтением исходного кода. Как читать нотацию — представление «L1».
Односторонняя синхронизация учётных записей из ядра платформы во внешний провайдер идентификации: созданный или изменённый пользователь вместе с профилем, принадлежностью организации и метаданными появляется в Zitadel, где на этих данных строится авторизация доменных сервисов. Работает консьюмером Kafka-топика, отдельный консольный режим использовался для первичной массовой миграции пользователей и компаний. Входящих вызовов не принимает.

Стек: Python · консьюмер Kafka (kafka-python) · requests с ретраями · Zitadel Management API.
Универсальное хранилище файловых вложений к любым сущностям платформы: файл кладётся в S3, метаданные — в PostgreSQL, привязка полиморфная («имя модели + идентификатор экземпляра»). Скачивание идёт по временным подписанным ссылкам напрямую из объектного хранилища.

Стек: Python · FastAPI · PostgreSQL (psycopg2, сырой SQL; Alembic только для схемы) · S3 через boto3 · OpenTelemetry.
Входная точка авторизации платформы: страницы `/login`, `/logout`, `/auth/callback`, `/auth/error` и обработка OIDC-редиректов Zitadel по Authorization Code flow. Полученные токены передаются в оболочку микрофронтендов; бизнес-данных компонент не хранит.

Стек: TypeScript · React · Webpack 5 · внутренний sdk-js поверх oidc-client · Zitadel (OIDC) · oauth2-proxy в инфраструктуре.
Ядро работы с информационными моделями: хранит BIM-модели проекта, дерево элементов, их свойства и статусную модель хода строительства (в том числе корпоративные шаблоны статусов с цветами и переходами). Питает раскраску моделей во вьюере, фильтрацию элементов и отчётность о проценте готовности.

Стек: Go (go-pg, gorilla/mux, Prometheus) и легаси-часть на Python/Flask · PostgreSQL с шардированием и партиционированием · S3 · джоб metadata-inserter на Go.
Среда общих данных (CDE): документы, версии, комплекты, права, штампы, QR-метки, электронные подписи, публичные ссылки и changelog. Публикует доменные события через transactional outbox в Kafka и постепенно принимает на себя мутирующие вызовы legacy-сервисов документации.

Стек: Go (Fiber, go-pg) · PostgreSQL · S3/MinIO · Valkey · Kafka (transactional outbox) · Camunda 8 / Zeebe · OpenTelemetry.
Шаблоны проверок (чек-листы из шагов и типизированных элементов ввода) и результаты их заполнения. Результат привязывается к любой сущности платформы через пару «тип сущности + идентификатор» и может блокироваться после согласования по вызову из flows.

Стек: Python · FastAPI · Piccolo ORM с админкой · PostgreSQL (JSONB) · собственный JWT-middleware · OpenTelemetry.
Сравнение проектных данных и выявление отклонений: облако точек к облаку, облако к модели, PDF к PDF, BIM к BIM, расчёт отклонений. Тяжёлые вычисления делегируются движку workflow, результат раскладывается на элементы и изменения, доступные для фильтрации и верификации инженером.

Стек: Go (Fiber, go-pg) · PostgreSQL · Docker-образы задач в реестре · фронтенд на TypeScript/React/MobX/Material-UI (Module Federation).
Реестр договоров компании: номер, подрядчик, сроки, стоимость, привязка к проекту или объекту. Даёт коммерческий контур поверх производственных данных; на договор, в частности, ссылается предписание.

Стек: Go · Fiber v3 · pgx + squirrel · PostgreSQL (JSONB) · фронтенд на TypeScript/React/MobX по Feature-Sliced Design.
Административный контур платформы (srx-admin): управление пользователями, ролями, атрибутами, подразделениями, проектами и функциональными группами, а также реестром активов компании с правами доступа. Отдельный крупный сценарий — пакетный импорт активов из XLSX со статусами заданий и отчётами об ошибках.

Стек: TypeScript · React · MobX · Material-UI и ui-kit · Webpack 5 Module Federation · монорепозиторий npm-workspaces; собственного хранилища нет.
Инструмент построения поперечных сечений по облакам точек и BIM-документам прямо во вьюере, с сохранением сечений, цветовой легендой документов и экспортом в DWG. Применяется при обмере и контроле построенного; серверная часть — drawings.

Стек: TypeScript · React · MobX · pixi-viewer · джоб экспорта в DWG на Go с Python-генератором · PostgreSQL · объектное хранилище.
Легаси-монолит и ядро продукта: компании, пользователи, роли и подрядчики, объекты строительства, миссии аэрофотосъёмки, ортофотопланы, облака точек и поверхности, измерения, аналитика с дашбордами и метриками, карта, ТОиР, уведомления и журнал действий. Здесь же — основной SPA-хост, в который встраиваются все микрофронтенды платформы.

Стек: Python · Django + DRF · django-guardian · channels · Celery + Redis · Kafka · PostgreSQL, ClickHouse, MongoDB, S3 · фронтенд на TypeScript/React/MobX (Module Federation, PWA).
Публичная страница выданной наружу ссылки на документ: получатель без учётной записи видит карточку документа и скачивает файл. Собственного бэкенда нет — данные отдаёт публичный эндпоинт documentations, срок действия ограничен JWT ссылки.

Стек: TypeScript · Next.js (app router) · React · SWR · Tailwind; собственного бэкенда нет.
Рабочая среда документации проекта: диски, дерево папок, документы с версиями, страницами, атрибутами, правами и связями; штампы, ЭЦП, подписки, корзина, публичные ссылки. Отвечает также за постановку загруженных инженерных форматов в очередь конвертации. Домен находится в миграции — мутирующие операции проксируются в cde.

Стек: Go (go-pg, Fiber, swaggo) · PostgreSQL · S3 с многочастной загрузкой · Valkey · RabbitMQ · Mailgun/SMTP · фронтенд на TypeScript/React/MobX.
Серверная часть сечений: хранит поперечные сечения по поверхностям и облакам точек и задания на их экспорт, принимает результат асинхронной выгрузки по webhook. Применяется при исполнительной съёмке и контроле выполненных объёмов.

Стек: Go · gorilla/mux · go-pg с миграциями · PostgreSQL · внутренние библиотеки gotools и sdk-go · Prometheus.
Универсальная модель «сущность — атрибут — значение»: пользовательские атрибуты, их типы, схемы и справочники, расширяющие любые доменные объекты без изменения схемы БД. Второй блок — иерархический классификатор активов объекта (WBS-дерево) с импортом и экспортом через Excel.

Стек: Python · Django + DRF · django-filter · Celery · PostgreSQL (в том числе сырой SQL для иерархии) · pandas + openpyxl · контракты protobuf.
Логическое имя слоя эфемерных вычислительных функций — одноразовых job-контейнеров, запускаемых движком workflow поверх Kubernetes. Отдельного репозитория и кодовой базы не найдено; значение компонента требует уточнения у команды платформы.

Стек: Предположительно Kubernetes Job и воркеры RabbitMQ поверх Docker-образов на Python и Go; собственной кодовой базы не найдено, стек требует подтверждения.
Маршруты согласования проектной документации: маршрут из шагов с назначенными согласующими, ревью документов, решения участников, сроки по рабочим дням и очередь задач согласующего. Публикует события согласования в Kafka и умеет автоматически инициировать трансмиттал после завершения маршрута.

Стек: Python · FastAPI · SQLAlchemy + Alembic · PostgreSQL (JSONB) · Celery · FastStream + Kafka · фронтенд на TypeScript/React/MobX (rsbuild + Module Federation).
Платформенный IAM: иерархия ресурсов, компании, пользователи, сервисные аккаунты и права по модели ReBAC (SpiceDB). Отвечает на вопросы «какие права у пользователя на ресурс» и «какие ресурсы доступны пользователю», на которые опираются остальные сервисы; пользователи заводятся во внешнем Zitadel.

Стек: Go, гексагональная архитектура · SpiceDB по gRPC с собственным Postgres-datastore · PostgreSQL · S3 · Kafka · Zitadel Management API · Helm с Istio.
События и проверки на объекте: планирование осмотров с типом, датой, ответственными, локацией и настраиваемыми атрибутами, контроль занятости исполнителей, история изменений и выгрузка реестра в XLSX. Отдельная подсистема — правила доступности и идемпотентное бронирование слотов для выездов и приёмок.

Стек: Python · FastAPI · Piccolo ORM с админкой · PostgreSQL (JSONB, триггеры, advisory-локи) · FastStream + Kafka · фронтенд на React/MobX с DevExpress Scheduler.
Сервис замечаний строительного контроля: типы, настраиваемые статусные модели с правами на переходы, ответственные, комментарии, фото-вложения, атрибуты EAV и история изменений. Включает выпуск предписаний, выгрузку реестров в XLSX и PDF и рассылку уведомлений. Один бэкенд обслуживает также компоненты remarks и prescriptions.

Стек: Python · Django + DRF · PostgreSQL с полнотекстовым поиском · Celery + Redis · Kafka · S3 · pandas и ReportLab для XLSX и PDF · SimpleJWT с Zitadel.
Агрегирующий сервис (BFF), склеивающий данные нескольких API в один ответ для интерфейса: реестр документов диска вместе с состоянием согласования и заметки вместе с их связями. Собственной доменной модели и базы не имеет, ответы кеширует в Redis.

Стек: Python · FastAPI · httpx с ретраями · Redis/RedisJSON как кеш; собственной БД нет.
Геопространственные измерения по материалам аэросъёмки: высота и температура в точке, профиль вдоль ломаной, расчёт объёма по контуру и разности объёмов между съёмками, метаданные растров и пересчёт координат. Stateless-сервис без собственной БД, читающий GeoTIFF напрямую из объектного хранилища.

Стек: Python · FastAPI · GDAL, pyproj, NumPy, OpenCV, SciPy · чтение GeoTIFF из S3 через boto3; собственной БД нет.
Событийный хаб домена планирования: принимает события Kafka и выполняет побочные действия — пересчёт аналитики, обновление атрибутов, письма, экспорты, системный журнал, автопланирование, синхронизацию проектов и ресурсов. Транслирует изменения в браузер по WebSocket, обеспечивая живое обновление доски проекта.

Стек: Python · FastStream + Kafka (aiokafka) · python-socketio с Redis · SQLAlchemy Core с сырым SQL к PostgreSQL · S3 · Jinja2 для писем.
Заметки и примечания на объектах проекта: пометка на 2D-чертеже или в 3D-модели со сроком, цветом, фотографиями, вложениями и связями с сущностями разных сервисов. Поддерживает отправку скриншота вида и формирование документа по заметке; применяется при авторском надзоре и строительном контроле.

Стек: Python · FastAPI · SQLAlchemy + Alembic · PostgreSQL с полнотекстовым поиском · фронтенд на TypeScript/React/MobX/Material-UI.
Календарно-сетевое планирование: иерархия задач, длительности, связи предшествования, календари, базовые планы, факт и проценты выполнения, ресурсы и назначения. Импорт графиков из MS Project, Primavera и XLSX, работа на диаграмме Ганта, экспорт в PDF, асинхронное автопланирование и пересчёт.

Стек: Python · Django 5 + DRF, целевой стиль — FastAPI с async SQLAlchemy · PostgreSQL с триггерами · ClickHouse · S3 · Celery + Redis · Kafka · pandas, парсеры MS Project и Primavera · фронтенд на React/MobX.
Выдача предписаний подрядчику по результатам строительного контроля: предписание собирается из замечаний, привязывается к договору, подрядчику и объекту, получает номер и проходит согласование по статусам. Официальный документ формируется по шаблону движком workflow; бэкенд — приложение внутри issues.

Стек: Python · Django + DRF · PostgreSQL (приложение внутри бэкенда issues) · генерация документов движком workflow · фронтенд на React/MobX (rsbuild + Module Federation).
Фабрика тяжёлых вычислений платформы: движок workflow исполняет граф задач, каждая из которых запускается отдельным контейнером (Kubernetes Job или воркер через RabbitMQ). Через него работают конвертация форматов, сравнения, экспорт в DWG и генерация документов; отдельный интерфейс даёт мониторинг, логи, отмену и перезапуск задач.

Стек: Go (pgx, go-pg, zap) · PostgreSQL · Kubernetes client-go для джобов · RabbitMQ для сторонних воркеров · джобы на Python (boto3, внутренняя workflows-tools) · фронтенд на React/MobX.
Витрина проектов и карточка проекта — верхнеуровневый вход пользователя в платформу: атрибуты, местоположение, фотографии, группировки и настраиваемые вкладки с разделами-виджетами. Агрегирует показатели остальных модулей, включая встраивание внешней аналитики.

Стек: Python · FastAPI · async SQLAlchemy 2.0 + Alembic · PostgreSQL (JSONB) · S3 · фронтенд на React/MobX с TanStack Query и leaflet · встраивание Superset.
Пользовательский модуль работы с замечаниями (UI): пин на чертеже, в ячейке XLSX или на задаче графика, описание, срок, ответственные, вложения и пометки поверх листа, табличное и списочное представления, фильтры, массовое редактирование и экспорт. Собственный бэкенд архивирован — модуль работает поверх issues.

Стек: TypeScript · React · MobX · Material-UI · TanStack Table и Virtual; серверная часть — стек issues.
Единый реестр ресурсов платформы — иерархия объектов строительства (проект, объект, участок и ниже) с типами, географическим положением, кодами и правами доступа. Идентификатор ресурса служит сквозным ключом проекта во всех остальных сервисах, а сам реестр — общей точкой проверки прав, поэтому это один из самых востребованных компонентов контура. Интеграция только синхронная, по HTTP.

Стек: Python · Django + DRF · django-filter · PostgreSQL с ltree и PostGIS · фронтенд в отдельном репозитории.
Рабочее место согласующего: очередь задач с приоритетами и сроками, просмотр документа, пометки и замечания, заполнение чек-листов и вынесение решения (согласовано / с замечаниями / отклонено). Ключевой этап между выпуском версии документа и выдачей её «в производство работ»; бэкенд общий с flows.

Стек: TypeScript · React · MobX · rsbuild + Module Federation; серверная часть — стек flows, экспорт отчётов вынесен в отдельный сервис.
Формальные запросы информации между участниками проекта: запрос с приоритетом, статусом, ответственными и привязкой к ресурсу, переписка сообщениями с пометкой одного из них как решения. Приоритеты и статусы настраиваются на уровне компании, ведётся полный журнал изменений полей.

Стек: Python · Django 5.1 + DRF · django-filter · PostgreSQL · Celery · SimpleJWT с Zitadel · фронтенд на TypeScript/React/MobX (rsbuild + Module Federation).
Публичная страница проверки подлинности документа по QR-штампу: сканирование кода с бумажной или PDF-копии открывает карточку с документом, страницей и его актуальным состоянием, включая статус согласования. Авторизация не требуется; серверная часть — публичный эндпоинт documentations.

Стек: Статический сайт без сборщика: HTML, vanilla JS, moment.js; серверная часть — Go (gorilla/mux, go-pg, PostgreSQL) в составе documentation-api.
Подписки на изменения объектов и рассылка уведомлений по e-mail, SMTP/Mailgun и Telegram с периодичностью от мгновенной до еженедельной. Источник изменений — не брокер, а периодический опрос журнала system-log; тексты формируются по шаблонам, привязанным к модели и типу события.

Стек: Python · Django + DRF · PostgreSQL с PostGIS и TimescaleDB · SMTP и Mailgun · python-telegram-bot · Jinja2 · OpenTelemetry.
Централизованный журнал системных событий (аудит) всей платформы: кто, что и над каким объектом сделал, с метаданными, ресурсом и компанией. Обеспечивает прослеживаемость изменений и служит источником событий для механизма подписок и уведомлений.

Стек: Go · Fiber · pgx + squirrel с миграциями на старте · PostgreSQL · Kafka через sarama (опционально) · отдельный воркер с cron · OpenTelemetry.
Формальная передача комплектов документации между участниками — сопроводительное письмо с составом, получателями, сроком и результатом приёма или отклонения. По завершении формируется акт передачи в PDF; есть шаблоны трансмитталов и связь с согласованиями, замыкающая цикл «выдал документацию → получил замечания».

Стек: Python · FastAPI · async SQLAlchemy + Alembic · PostgreSQL · S3 · taskiq + RabbitMQ · Jinja2 с собственным конвертером HTML в PDF · Mailgun и SMTP · фронтенд на React/MobX (Module Federation).
Рабочее пространство — сцена, в которой пользователь одновременно работает с BIM-моделями, облаками точек, PDF-чертежами и панорамами объекта, настраивает отображение и сохраняет именованные состояния. Поддерживает установку прикладных модулей компании как федеративных приложений внутри сцены и архивирование данных при закрытии этапов.

Стек: Go (gorilla/mux, go-pg, Prometheus, Sentry, JWT на RSA) · PostgreSQL · фронтенд на TypeScript/React/MobX с viewer (Module Federation), кеш в IndexedDB · тесты Cypress и Jest.
Подготовка исходных САПР-моделей (IFC, NWD и другие форматы Autodesk) к просмотру и анализу: облегчённая геометрия glTF/`.s3d` плюс структурированный набор свойств, категорий и материалов элементов. Обязательное звено между загрузкой документа в CDE и появлением работоспособной модели в интерфейсе; работает как эфемерный джоб и как постоянный воркер RPC.

Стек: Ядро на Python с ifcopenshell и NumPy · обвязка и воркеры на Go · RabbitMQ (RPC) · S3 · Docker · плагин Navisworks на C#/.NET (SharpGLTF) · форматы IFC и NWD в glTF/GLB, `.s3d` и JSON свойств.
Flux CD — набор контроллеров Kubernetes, реализующий подход GitOps: вся система описана декларативно и находится под контролем версий, а автоматика непрерывно приводит развёрнутое окружение в соответствие состоянию, заданному в Git. Контроллеры с заданным интервалом сравнивают фактическое состояние ресурсов с желаемым и применяют расхождения. Основные ресурсы: GitRepository описывает источник, Kustomization — набор манифестов для согласования, HelmRelease — развёртывание Helm-чарта.

Кластер Kubernetes, в котором работает вся платформа. Состав задаётся одним файлом clusters/<контур>/kustomization.yaml — плоским списком инфраструктурных компонентов и приложений; он же является источником истины о том, что развёрнуто. Доставка изменений — GitOps через FluxCD v2: Flux читает манифесты из Git-сервера контура и приводит кластер к описанному состоянию, ручной kubectl apply в нормальном процессе не используется. Прикладные сервисы ставятся не собственными чартами, а одним общим universal-chart, что делает их конфигурацию единообразной.
Istio — открытый service mesh, который прозрачно накладывается на существующие распределённые приложения и централизованно управляет взаимодействием сервисов, не требуя изменений в коде. Ingress-шлюз — это компонент плоскости данных Istio на границе mesh: он принимает внешний трафик, терминирует TLS и передаёт запросы внутрь по правилам, заданным ресурсами Gateway и VirtualService.

Единственная точка входа внешнего трафика в контур. Терминирует TLS и передаёт запросы дальше по правилам service mesh. Публикуется через NodePort и в типовой конфигурации привязан к выделенному узлу — это делает его единственной точкой отказа для всего внешнего доступа: при потере узла контур остаётся живым внутри, но недоступен снаружи. Резервирование ingress стоит рассматривать отдельно от резервирования приложений.
Istio разделён на плоскость управления, которая хранит конфигурацию и раздаёт её прокси, и плоскость данных из прокси Envoy рядом с каждым подом. Такая схема даёт три группы возможностей: управление трафиком (маршрутизация, балансировка HTTP/gRPC/TCP, повторы и переключение при отказах), безопасность (взаимный TLS между сервисами) и наблюдаемость — метрики, логи и трассировки для всего трафика кластера собираются автоматически. Конфигурация меняется на лету: Istio перепрограммирует прокси без пересборки и перезапуска приложений.

Управляющая конфигурация сети: Gateway описывает внешние точки входа, VirtualService — маршрутизацию по путям на конкретные сервисы, RequestAuthentication — проверку JWT на входе. Поставляется чартом istio-config-contour и является тем местом, где видно, какие приложения вообще опубликованы наружу. В части контуров разводка по путям вынесена за пределы репозитория во внешний nginx — тогда в модели виден только факт публикации, но не таблица маршрутов. Sidecar-прокси рядом с каждым подом дают mTLS между сервисами и метрики трафика.
cert-manager — расширение Kubernetes, которое выпускает TLS-сертификаты для нагрузок в кластере и продлевает их до истечения срока. Ресурсы Issuer и ClusterIssuer описывают, у какого удостоверяющего центра и на каких условиях получать сертификат, а ресурс Certificate — сам запрошенный сертификат; результат складывается в секрет Kubernetes, откуда его читают поды и ingress-контроллеры. Поддерживаются разные источники: Let's Encrypt, HashiCorp Vault, внутренние PKI и самоподписанные издатели.

Выпускает и автоматически продлевает TLS-сертификаты для внешних доменов контура. Работает через ClusterIssuer: в контурах с доступом в интернет это Let's Encrypt, в закрытых — самоподписанный издатель, как в этом примере. Выпущенный wildcard-сертификат складывается в секрет, который использует ingress-gateway. Практическое следствие самоподписанного варианта: клиентам нужно доверять корневому сертификату контура, иначе браузеры и интеграции будут ругаться.
Zitadel — платформа управления идентификацией, реализующая отраслевые стандарты OIDC, OAuth 2.0 и SAML для входа и единой аутентификации. Отличительные черты — мультиарендность с настройкой оформления под каждого арендатора, полный журнал аудита на основе event sourcing и возможность развёртывания как в облаке, так и на своих мощностях. Закрывает задачи аутентификации, многофакторной проверки и управления пользователями без разработки собственной подсистемы входа.

Основной поставщик идентичности платформы, отвечает за аутентификацию пользователей по OIDC и выдачу токенов. Прикладные сервисы не проверяют пароли сами: они валидируют JWT по публичному ключу, а на границе контура это же делает Istio через RequestAuthentication. Самый широко используемый технологический сервис контура — с ним так или иначе работает подавляющее большинство приложений, включая фронтенды. Отдельный микрофронтенд auth-flow обслуживает сценарий логина и обработку OIDC-callback. Keycloak в платформе тоже встречается, но как вторичный вариант и внутри поставки Camunda.
HashiCorp Vault — централизованная система управления секретами: учётными данными, ключами шифрования и сертификатами, с аудитом всех обращений. Работает по схеме «клиент аутентифицируется — получает токен, связанный с набором политик — обращается к секретам по путям — Vault проверяет права и записывает обращение в журнал независимо от исхода». Модульная архитектура позволяет подключать разные способы аутентификации и разные хранилища секретов, включая выдачу временных учётных данных к базам данных.

Единственный механизм доставки секретов приложениям. Секреты не лежат в манифестах и не хранятся в Git: под получает их через sidecar Agent Injector, который аутентифицируется в Vault по service account пода и монтирует значения из пути вида secrets/data/apps/<приложение>/postgres. Ролью и service account служит имя приложения — соглашение единообразно для всех сервисов. Трафик к Vault выведен из-под sidecar-прокси Istio отдельной аннотацией, иначе инициализация пода не проходит.
PostgreSQL — объектно-реляционная СУБД с открытым исходным кодом и почти сорокалетней историей развития. Соответствует требованиям ACID, использует многоверсионное управление конкурентным доступом (MVCC) и покрывает не менее 170 из 177 обязательных возможностей ядра стандарта SQL:2023. Поддерживает широкий набор типов данных, включая JSON и JSONB, геометрические и пользовательские типы, а также расширения — хранимые процедуры на нескольких языках, обёртки сторонних источников данных и геопространственное расширение PostGIS.

Основное реляционное хранилище контура и самый востребованный технологический сервис после управления секретами. Разворачивается внутри кластера как StatefulSet на сетевом хранилище; в части контуров вместо него используется внешняя managed-СУБД, и тогда в кластере остаются только реквизиты подключения. Базы разделены по приложениям — общей схемы нет, каждый сервис владеет своими таблицами, что важно для независимости релизов. Реквизиты всегда приходят через Vault, поэтому в манифестах приложения видна лишь аннотация инжектора.
Redis — сервер структур данных, хранящий данные в оперативной памяти. Помимо строк поддерживает хеши, списки, множества, упорядоченные множества и потоки — журнал с добавлением в конец. Такой набор примитивов закрывает разные задачи одним инструментом: кэширование, хранение сессий, очереди, счётчики и обработку событий. Предусмотрены механизмы сохранения данных на диск, что позволяет пережить перезапуск.

Кэш и брокер фоновых задач. В отличие от PostgreSQL, не является общей инфраструктурой контура: разворачивается точечно, в namespace тех приложений, которым он действительно нужен — как правило, там, где есть Celery-воркеры или требуется разделяемое состояние между репликами. Из-за этого экземпляров Redis в контуре несколько и они независимы; общего кэша, через который сервисы обмениваются данными, в платформе нет.
Apache Kafka — платформа потоковой обработки событий: публикация, хранение и обработка непрерывных потоков данных в реальном времени. События пишутся в темы, темы делятся на разделы и распределяются по брокерам ради масштабирования; производители пишут, потребители читают. Ключевое отличие от обычной очереди в том, что событие не удаляется после прочтения, а хранится по настраиваемой политике — поэтому его можно перечитать заново и подключить новых потребителей к уже накопленной истории.

Шина событий для асинхронного обмена между сервисами. Используется там, где нужен журнал событий с возможностью повторного чтения и несколькими независимыми потребителями: аудит действий, уведомления, синхронизация состояний между доменами. Соседствует с RabbitMQ, и это осознанное разделение, а не дублирование: Kafka отвечает за поток событий, RabbitMQ — за адресную доставку задач. Часть приложений подключена к обеим шинам одновременно.
RabbitMQ — брокер сообщений, реализующий протокол AMQP 0-9-1 для асинхронного обмена между приложениями. Опубликованное сообщение попадает в обменник, привязки маршрутизируют его в очереди по ключу маршрутизации, а из очередей его забирают потребители. Доставка подтверждается: при явном подтверждении потребитель сообщает об успешной обработке, и если он отвалился, не подтвердив сообщение, брокер передаст его другому потребителю или дождётся появления нового — сообщение не теряется.

Очередь задач для фоновой обработки: выгрузки, конвертация документов, рассылки, длительные операции, которые нельзя выполнять в HTTP-запросе. В отличие от Kafka, ориентирован на адресную доставку конкретному обработчику с подтверждением и повторами. В ряде контуров панель управления публикуется наружу отдельным доменом, что удобно для эксплуатации, но требует внимания к доступу — это полноценный административный интерфейс.
Camunda 8 — платформа оркестрации и автоматизации бизнес-процессов с участием людей, систем и устройств. В её основе движок Zeebe, координирующий исполнение процессов в распределённой среде; Operate и Tasklist дают операционную видимость и работу с пользовательскими задачами, Optimize — аналитику по исполнению. Работу выполняют job-воркеры: внешние компоненты, которые опрашивают кластер на предмет заданий своего типа, обрабатывают их и возвращают результат.

Движок исполнения бизнес-процессов в нотации BPMN. Через него проходят маршруты согласования документов: процесс описывает шаги и условия, а конкретные действия выполняют воркеры прикладных сервисов, подключённые к Zeebe как job-workers по типу задачи. Это единственный компонент контура, где логика согласования выражена декларативно и её можно менять без пересборки сервисов. Важная особенность для чтения конфигурации: переменные ZEEBE_* и CAMUNDA_* приходят из k8s-секрета, поэтому в манифестах приложений связь с Camunda не видна — она подтверждается только документацией сервисов.
Ядро движка: хранит состояние запущенных процессов и раздаёт задачи воркерам. Работает как StatefulSet, состояние на диске.
Точка подключения клиентов и job-workers к ядру. Именно её адрес прикладные сервисы получают в переменной ZEEBE_GATEWAY.
Интерфейс и REST API для наблюдения за экземплярами процессов: где застрял маршрут, какие переменные, какие инциденты. Используется не только людьми — прикладные сервисы обращаются к его API программно.
Интерфейс пользовательских задач BPMN — шагов процесса, требующих действия человека.
Аналитика по исполнению процессов: длительности, узкие места, статистика прохождения маршрутов.
Управление доступом к компонентам Camunda и выдача OAuth-токенов для машинного доступа. В поставке идёт вместе с собственным Keycloak, отдельным от основного поставщика идентичности контура.
Готовые коннекторы к внешним системам, вызываемые из процесса без написания своего воркера.
Объектное хранилище — масштабируемый репозиторий для неструктурированных данных: файлов, медиа, журналов и резервных копий, без ограничений традиционной файловой системы. Отраслевым стандартом доступа стал API S3, поэтому такие хранилища взаимозаменяемы для приложения. В self-hosted варианте обычно применяется MinIO с S3-совместимым API и распределённым развёртыванием на основе избыточного кодирования (erasure coding): данные разрезаются на фрагменты с избыточностью и раскладываются по узлам, что позволяет пережить отказ части из них дешевле, чем при простом дублировании.

Хранилище файлов платформы: документы, чертежи, модели, вложения, результаты конвертации. Вынесено за пределы кластера — в одних контурах это MinIO на отдельных узлах, в других внешний S3-совместимый сервис заказчика. Именно здесь лежит основной объём данных: базы хранят метаданные и связи, а сами файлы всегда в объектном хранилище. Прямой доступ браузера к хранилищу не используется, отдача файлов идёт через прокси-сервис платформы.
Класс хранения, из которого выделяются тома для компонентов с состоянием — прежде всего для PostgreSQL, а также для брокеров и движка процессов. От его производительности напрямую зависит отзывчивость СУБД, поэтому это место стоит проверять первым при жалобах на медленную работу платформы.
Хранит манифесты, из которых Flux собирает состояние кластера. В закрытых контурах наполняется зеркалированием из основного репозитория разработки, что даёт контуру автономность: даже при отсутствии связи с внешним миром развёртывание работает из локальной копии. Практически это означает, что изменение, попавшее в основной репозиторий, доедет до контура не мгновенно, а после синхронизации зеркала.
Реестр, из которого кластер получает и Helm-чарты (в формате OCI), и образы контейнеров. Единая точка поставки: версия чарта и тег образа, указанные в манифестах, разрешаются именно здесь. Доступность реестра — обязательное условие для развёртывания и перезапуска подов, поэтому в закрытых контурах он размещается внутри периметра.
SMTP — протокол передачи почты. Релей заказчика принимает исходящие сообщения от приложений контура и доставляет их адресатам; приложение аутентифицируется логином и паролем сервисной учётной записи, транспорт защищается TLS — либо сразу (порт 465), либо через STARTTLS (порт 587).

Единственный канал, которым платформа по своей инициативе выходит за периметр: уведомления о назначенных задачах, замечаниях, запросах и отправленных трансмитталах. Адрес релея, порт и учётные данные задаются переменными окружения приложений. Отказ релея не останавливает работу платформы — перестают доходить только письма, и это стоит проверять первым при жалобах «уведомления не приходят».
Keycloak — открытый сервер управления доступом: поддерживает OIDC, OAuth 2.0 и SAML, умеет подтягивать пользователей из LDAP и Active Directory и принимать доменный вход по Kerberos (механизм SPNEGO). В схеме интеграции работает брокером: для платформы это обычный OIDC-провайдер, а в сторону предприятия — клиент корпоративного каталога.

Появляется в контуре там, где провайдер идентификации платформы не может обратиться к каталогу заказчика напрямую: нужен прозрачный доменный вход, источников пользователей несколько или каталог опубликован по SAML. Платформа поставляет чарт keycloak-contour, поэтому брокер может стоять как на стороне заказчика, так и внутри контура. Цена варианта — лишнее звено в цепочке входа: при недоступности брокера вход невозможен, даже если каталог и провайдер идентификации работают.
Active Directory Federation Services — служба федерации Microsoft поверх домена Active Directory. Выдаёт токены по SAML 2.0, WS-Federation и OIDC, а проверку самих учётных данных оставляет домену.

Альтернатива брокеру в тех контурах, где федеративная служба у заказчика уже развёрнута и является штатной точкой входа для корпоративных систем. Для платформы подключается как внешний провайдер идентификации: собственных учётных записей платформа при этом не заводит, а получает утверждения о пользователе от службы федерации.
Active Directory — служба каталогов Microsoft: хранит учётные записи, группы и организационную структуру предприятия и отвечает на запросы по LDAP (порт 389) и LDAPS (порт 636). Для предприятия это источник истины о сотрудниках.

Каталог заказчика — то, откуда пользователи попадают в платформу. Схем подключения четыре: напрямую к провайдеру идентификации платформы по LDAPS; через брокер Keycloak; через брокер с доменным входом по Kerberos; через службу федерации AD FS. Выбор делается при развёртывании и определяет, какие из внешних узлов этой группы вообще появятся в контуре. Общее у всех четырёх одно: учётные записи платформа не заводит, а получает, поэтому отключение сотрудника в каталоге закрывает ему и доступ в платформу.
Kerberos — протокол сетевой аутентификации на билетах, встроенный в домен Active Directory. Центр выдачи билетов работает на контроллерах домена и слушает порт 88 по TCP и UDP.

Нужен только ради прозрачного входа: пользователь, уже вошедший в домен на рабочей станции, попадает в платформу без повторного ввода пароля. Билет проверяет брокер по механизму SPNEGO, поэтому сценарий с Kerberos всегда предполагает брокер в цепочке. Работает лишь для рабочих станций внутри домена — внешние подрядчики в этом же контуре входят обычным паролем.
Узел, к которому привязан ingress-gateway через nodeSelector. Привязка сделана ради предсказуемого адреса для внешней балансировки и правил межсетевого экрана, но ценой того, что внешний доступ зависит от одного узла.
Публикация приложений наружу: терминация TLS, разбор внешнего домена и пути, направление запроса нужному сервису, проверка токена на границе. Сервисом пользуются только те приложения, у которых есть внешний интерфейс; остальные доступны исключительно внутри кластера.
Автоматическое получение и продление сертификатов для доменов контура. Потребитель у сервиса один — ingress-gateway; приложения с ним не взаимодействуют, поэтому отдельного представления с потребителями у него нет.
Проверка личности пользователя и выдача токена, по которому сервисы принимают решение о доступе. Самый массово используемый сервис контура. Значительная часть связей подтверждается только документацией приложений: публичный ключ и параметры подключения приходят из секретов, а не из манифестов.
Выдача приложениям реквизитов доступа к базам, брокерам и хранилищам во время запуска пода. Практически универсальная зависимость: почти каждый сервис с состоянием стартует только после успешного получения секретов, поэтому недоступность этого сервиса останавливает не работу, а перезапуск и выкатку.
Хранение структурированных данных доменных областей: карточек, связей, статусов, журналов. У каждого сервиса своя база, общей схемы нет — обмен между сервисами идёт через API и шины, а не через общие таблицы.
Разделяемое короткоживущее состояние и очередь фоновых задач для сервисов с Celery-воркерами. Востребован узким кругом приложений, поэтому разворачивается точечно, а не как общая инфраструктура контура.
Асинхронная публикация событий с сохранением журнала и несколькими независимыми потребителями. Используется там, где важен факт изменения и возможность его повторно прочитать: аудит, уведомления, синхронизация состояний между доменами.
Адресная доставка задач фоновым обработчикам с подтверждением и повторами. Обслуживает длительные операции — конвертацию, выгрузки, рассылки, — которые нельзя выполнять внутри HTTP-запроса.
Исполнение маршрутов согласования, описанных схемой BPMN: движок ведёт состояние процесса и раздаёт шаги воркерам прикладных сервисов. Позволяет менять логику согласования без пересборки сервисов. Связь с потребителем не видна в манифестах — параметры подключения приходят из секрета.
Хранение и выдача файлов: документов, чертежей, моделей, вложений и производных представлений. Базовый сервис для всех документоориентированных областей платформы — в реляционных базах лежат только метаданные, содержимое всегда здесь.
Отправка исходящей почты приложениями контура. Собственного почтового сервера платформа не содержит — сервис реализуется релеем заказчика. Через него уходят уведомления о назначенных задачах, замечаниях, запросах и отправленных трансмитталах.
Узлы под вычислительно тяжёлую обработку, вынесенную из общего пула приложений: конвертация и разбор файлов, построение производных представлений документов и моделей. Отделены от остальных прикладных серверов намеренно — такая нагрузка неравномерна и способна вытеснить интерактивные сервисы, если делить с ними ресурсы.
Основной пул прикладных серверов: здесь работает подавляющее большинство сервисов платформы — и бэкенды доменных областей, и микрофронтенды. Нагрузка преимущественно интерактивная, запрос-ответ. Это самая массовая группа, и именно её объём определяет, сколько ресурсов требует контур.
Узлы файлового хранилища. Отделены от вычислительных, потому что растут по другому закону: объём здесь определяется накопленными документами и моделями за всё время эксплуатации, а не числом одновременных пользователей. Это же делает группу главным кандидатом на резервное копирование.
Узлы СУБД. Вынесены отдельно по двум причинам: предсказуемая производительность дисков и возможность обслуживать базы, не затрагивая прикладные сервисы. Хранят метаданные и связи всех доменных областей; при потере данных этой группы файлы в объектном хранилище останутся, но станут неадресуемыми.
Узлы платформенных сервисов, на которых не работает прикладная логика: сеть и вход в контур, идентификация, секреты, брокеры, движок процессов, кэш. Прикладные сервисы без этой группы нефункциональны — здесь сосредоточены зависимости, общие для всех доменных областей.
Узлы поставки: реестр чартов и образов, а также Git-сервер, из которого Flux читает манифесты. Обеспечивают автономность контура — развёртывание и перезапуск не требуют выхода во внешнюю сеть. Состав группы требует подтверждения: не исключено, что под репозиторием компонентов понимается только реестр артефактов.
Узлы обработки исходных файлов BIM-моделей в проприетарных форматах NWD и RVT. Работают асинхронно: воркер разбирает очередь заданий, забирает исходный файл из объектного хранилища, конвертирует его в пригодный для просмотра и анализа вид и складывает результат обратно. Вынесены в отдельную группу, потому что требуют специфического окружения и дают тяжёлую неравномерную нагрузку — обработка одной модели занимает несоизмеримо больше времени, чем любой интерактивный запрос. В манифестах кластера этих компонентов нет: группа обслуживается вне GitOps-контура платформы.
Общие механизмы, на которые опираются все прикладные домены: единая точка входа в интерфейс, вход и права, справочник атрибутов, рабочие пространства и проекты как контейнеры данных, журнал действий, уведомления, оркестрация процессов.

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

Группа потребляет данные остальных доменов чаще, чем отдаёт: план и договор ссылаются на документы, замечания и полевые измерения, обратные ссылки редки.
Ядро CDE: хранение документов и их версий, связи между документами, вложения, комплекты передачи, чертежи и трёхмерные модели, подготовка САПР-моделей к просмотру, проверка штампов.

Самая нагруженная группа по числу входящих ссылок — на документ ссылается почти каждый прикладной сценарий. Хранилище документов здесь же является и самым связанным компонентом всей платформы.
Работа с несоответствиями: инспекции и чек-листы, замечания, проблемы, запросы информации, ревью, предписания, сравнение редакций чертежей.

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

Единственная группа с существенной вычислительной нагрузкой: обработка вынесена на отдельные узлы, потому что её всплески не должны мешать интерактивной работе остальных сервисов.
Легенда нотации. Показан настоящий фрагмент модели, подписанный по типам: каждый элемент и каждая линия здесь встречаются на остальных представлениях в том же начертании.
Стрелка serving читается не как «кто кого вызывает», а как «кто без кого не работает»: она идёт от обслуживающего к обслуживаемому. Направление выбрано так потому, что от схемы обычно нужен ответ на вопрос «что откажет, если убрать этот элемент», — и он читается по стрелкам вперёд.
Узел (Node) — вычислительная среда: кластер, группа серверов или отдельный хост. Ромб на линии — composition: узел состоит из этого, и отдельно от узла содержимое не существует.
Системное ПО (System Software) — платформенный компонент внутри узла. Пунктир с полым треугольником — realization: компонент реализует технологический сервис.
Технологический сервис (Technology Service) — что платформа даёт приложениям, без указания, чем именно это сделано. Приложение зависит от сервиса, а не от конкретного продукта под ним.
Прикладной компонент (Application Component) — сервис прикладного слоя. Цветом различаются слои: голубой — прикладной, зелёный — технологический.
Линия с полым ромбом — aggregation: группа объединяет элемент, но тот может существовать и без неё. Так показано, на каких узлах работает системное ПО.
Линия с шариком и закрашенной стрелкой — assignment: узел выделен под компонент, и компонент на нём исполняется.
Смысловая группа (Grouping) — домен прикладного слоя. Тоже aggregation: компонент принадлежит домену по смыслу, а не по месту размещения.
Артефакт (Artifact) — то, что физически лежит в хранилище: файл, образ контейнера, дистрибутив.
Что развёрнуто в кластере и какие технологические сервисы это даёт. Приложения-потребители вынесены в отдельные представления T2 и далее.
Какие группы узлов какие компоненты несут. Вложенность заменяет стрелки: хост внутри группы — composition, приложение — assignment, системное ПО — aggregation. Имена хостов заданы в профиле контура.
Системы за периметром контура, с которыми платформа обменивается данными, и направление зависимости. Слева — технологические сервисы, которые видят приложения; справа — то, чем эти сервисы обеспечены на стороне заказчика.

Схем подключения каталога предприятия четыре, и в конкретном контуре работает одна: каталог напрямую к провайдеру идентификации платформы; каталог через брокер Keycloak; то же с доменным входом по Kerberos, который умеет проверять только брокер; либо служба федерации AD FS поверх того же каталога. Здесь показаны все четыре сразу — при развёртывании лишние узлы из профиля убираются.
Сервисом пользуется 21 из 37 приложений контура.
Сервисом пользуются 25 из 37 приложений контура.
Сервисом пользуются 26 из 37 приложений контура.
Сервисом пользуются 24 из 37 приложений контура.
Сервисом пользуются 5 из 37 приложений контура.
Сервисом пользуются 14 из 37 приложений контура.
Сервисом пользуются 12 из 37 приложений контура.
Сервисом пользуется 1 из 37 приложений контура.
Сервисом пользуются 16 из 37 приложений контура.
Сервисом пользуются 6 из 37 приложений контура.
Из чего состоит прикладной слой: 38 компонентов по смысловым группам. Связи здесь намеренно не показаны — на таком числе компонентов они делают схему нечитаемой; для них есть представления A1 и далее. Вложенность означает aggregation: группа объединяет компоненты, но не владеет ими.
Восемь сервисов с наибольшим числом связей и вызовы между ними. Стрелка идёт от вызываемого к вызывающему (serving): кого лишишься — тот и сломается. Всего в контуре 86 межсервисных связей.
К django обращаются 18 сервисов.
К documentations обращаются 11 сервисов.
К eav обращаются 9 сервисов.
К resources обращаются 7 сервисов.
К processing обращаются 6 сервисов.
К iam обращаются 6 сервисов.
К flows обращаются 4 сервиса.
К workspaces обращаются 4 сервиса.
К system-log обращаются 3 сервиса.
К bim обращаются 3 сервиса.
К pm обращаются 3 сервиса.
Что нужно, чтобы documentations работал: 7 технологических сервисов и 15 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого documentations — представление A3.
Что нужно, чтобы flows работал: 7 технологических сервисов и 8 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого flows — представление A8.
Что нужно, чтобы issues работал: 9 технологических сервисов и 7 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у issues меньше 3, отдельного представления для них нет.
Что нужно, чтобы comparisons работал: 3 технологических сервиса и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у comparisons меньше 3, отдельного представления для них нет.
Что нужно, чтобы django работал: 8 технологических сервисов и 6 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого django — представление A2.
Что нужно, чтобы faas работал: 0 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у faas меньше 3, отдельного представления для них нет.
Что нужно, чтобы transmittal работал: 6 технологических сервисов и 5 прикладных сервисов. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у transmittal меньше 3, отдельного представления для них нет.
Что нужно, чтобы message-hub работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у message-hub меньше 3, отдельного представления для них нет.
Что нужно, чтобы pm работал: 8 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого pm — представление A12.
Что нужно, чтобы processing работал: 5 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Кто зависит от самого processing — представление A6.
Что нужно, чтобы rfi работал: 7 технологических сервисов и 4 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у rfi меньше 3, отдельного представления для них нет.
Что нужно, чтобы cde работал: 5 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у cde меньше 3, отдельного представления для них нет.
Что нужно, чтобы notes работал: 6 технологических сервисов и 3 прикладных сервиса. Стрелки, как и везде, идут от обслуживающего к обслуживаемому. Входящих вызовов у notes меньше 3, отдельного представления для них нет.