Архитектурные рекомендации
=============================

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

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


Минимальные требования к инфраструктуре
----------------------------------------

При выборе инфраструктуры рекомендуется исходить
из целевого сценария использования платформы
и предполагаемой нагрузки.


Enterprise Instance
~~~~~~~~~~~~~~~~~~~

**Enterprise Instance** предназначен для промышленной эксплуатации
и рассчитан на нагрузку до **1000 именованных пользователей**
и до **300 конкурентных пользователей**.

Целевой показатель SLA — время отклика до **3 секунд**
при стабильной нагрузке.

Минимальные требования к инфраструктуре:

* **CPU**: 16 vCPU  
* **RAM**: 64 GB  
* **Storage**: 1 TB NVMe  
* **Network**: до 20 TB трафика  

Оценочная стоимость аренды виртуальной машины
с такими характеристиками составляет
порядка **150–200 USD в месяц**.

Данный вариант рекомендуется
для production-окружений и корпоративных внедрений.


Dev Instance
~~~~~~~~~~~~

**Dev Instance** предназначен для:

* разработки;
* демонстрации решений;
* показа кейсов и прототипов.

Рассчитан на нагрузку до **5 конкурентных пользователей**.

Минимальные требования:

* **CPU**: 4 vCPU  
* **RAM**: 8 GB  
* **Storage**: ~25 GB  
* **Network**: минимальные, зависят от сценария использования  

В качестве Dev Instance
может использоваться рабочий ноутбук разработчика
или недорогая виртуальная машина.

Мультиинстанс-архитектура (process-to-process)
----------------------------------------------

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

Суть подхода заключается в том, что экземпляры Synergy
разворачиваются по логике организационной структуры:
отдельный инстанс - на отдельную организационную единицу
(например, на каждую дочернюю организацию или крупный контур).

Данный подход позволяет:

* изолировать процессы и данные между организационными единицами;
* повысить уровень безопасности за счет разделения контуров доступа;
* повысить отказоустойчивость (сбой в одном инстансе
  не останавливает работу остальных);
* упростить масштабирование за счет распределения нагрузки
  по нескольким инстансам;
* поддерживать независимые циклы изменений и сопровождения
  для разных контуров.

При использовании мультиинстанс-архитектуры допускается построение
process-to-process взаимодействия между инстансами,
когда выполнение процесса в одном инстансе
может инициировать продолжение или отдельный участок процесса
в другом инстансе (в рамках общей бизнес-логики компании).

Сводный инстанс
~~~~~~~~~~~~~~~

Дополнительно может быть выделен **сводный инстанс**,
который используется как общий уровень для:

* централизованных справочников;
* сводной отчетности и аналитики;
* консолидации результатов процессов из дочерних контуров.

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

.. note::
   Выбор мультиинстанс-архитектуры рекомендуется
   при наличии нескольких организационных контуров
   и необходимости разделения доступа, ответственности и нагрузки.



Архитектурные рекомендации по пользовательским порталам
--------------------------------------------------------

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


Сценарий до 1000 конкурентных пользователей
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

При нагрузке до **1000 конкурентных пользователей**
рекомендуется использовать стандартные средства платформы Synergy.

В данном сценарии:

* пользовательский портал реализуется непосредственно на Synergy;
* формы, бизнес-валидации, маршруты и транзакции
  выполняются внутри платформы;
* инфраструктурные требования минимальны;
* профиль нагрузки предсказуем.

Такой подход обеспечивает:

* быстрый **time-to-market**;
* упрощенную архитектуру;
* снижение эксплуатационных затрат.


Сценарий свыше 1000 конкурентных пользователей
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Нагрузка свыше **1000 конкурентных пользователей**
относится к классу **highload**
и требует отдельного архитектурного проектирования.

В данном случае рекомендуется:

* разрабатывать внешний пользовательский портал
  как самостоятельное highload-приложение;
* применять горизонтальное масштабирование;
* проектировать архитектуру под конкретный профиль нагрузки.

Взаимодействие с Synergy
в этом сценарии должно выполняться:

* асинхронно;
* через очереди сообщений;
* с обязательным использованием **rate limiting**;
* исключительно через API и события.

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


Общие рекомендации
------------------

При выборе архитектурного подхода рекомендуется:

* четко определять целевой профиль нагрузки;
* избегать преждевременной оптимизации;
* использовать стандартные средства Synergy
  при умеренных нагрузках;
* выносить highload-компоненты во внешние сервисы
  только при наличии объективной необходимости.

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