# Архитектурный анализ размещения и разбиения shared-sqs (2026-10-08)

**Роль:** архитектор. **Статус:** решения согласованы с владельцем, записаны для исполнения.

---

## 1. Исходные требования (согласовано)

1. **SQS должен быть полноценным публичным сервисом** — как AWS SQS и Yandex YMQ.
   Клиенты ходят к нему снаружи по HTTPS через AWS SDK. Внешний доступ — обязателен,
   а не опция.
2. **Без монолитов** — но с уточнением (раздел 3): не «микросервисы ради микросервисов»,
   а «разные процессы там, где разные требования».
3. **Девопсов не дёргать сейчас** — у них и так заботы.

## 2. Сетевая стратегия (две беды платформы, обход)

См. `nubes-large-body-workaround-findings-2026-10-08.md` и
`nubes-workaround-applicability-to-sqs-2026-10-08.md`.

**Две независимые беды managed-шлюза:**
- A. Большие пакеты/тела не проходят (MSS 1448 при underlay 1450, PMTUD мёртв) — ~51 с;
- B. Таймауты/RST на ЛЮБЫХ телах из-за таймеров шлюза (период 31–33 с; keep-alive 10 в drhider).

Обе — на стороне платформы, тикет не решает (доказано опытом drhider).

**Принятая стратегия:**
1. Сейчас — публичная точка входа на **ВМ** (наш nginx, TLS, MTU, keep-alive), минуя
   managed-шлюз. Полный контроль, девопсы не нужны.
2. Когда сервис отлажен и появились реальные клиенты — к девопсам с накопленными
   доказательствами (tcpdump, период 31–33 с, MSS 1448, опыт drhider), просить чинить
   managed-шлюз уже предметно.

**Уточнение про «в кубере та же хуйня»:** она есть только на пути через managed
ingress извне. Внутри кластера сеть чистая (6–8 мс, без таймаутов).

## 3. Разбиение: «модульный монолит», а не микросервисы

Вывод обсуждения: монолит плох там, где смешивает разное; микросервисы — плата
(сеть, распределённые транзакции, оркестрация, дебаг), которая для стадии
«никто не использует, один человек» преждевременна.

**Критерии, по которым решаем, выносить ли в отдельный процесс:**
1. разный профиль нагрузки/масштабирования;
2. разный жизненный цикл / частота релизов;
3. stateful vs stateless.

**Целевое разбиение SQS:**

| Компонент | Отдельный процесс? | Обоснование |
|---|---|---|
| SQS **data-plane** (очереди, сообщения, SigV4) | **да** | горячий путь, stateful, свой профиль |
| **control-plane** (тенанты, креды, очереди, админ) | **да** | редкие операции, другой жизненный цикл и периметр |
| биллинг | модуль внутри | выносить = сеть ради одной горутины, пишущей в PG |
| метрики (Prometheus) | модуль внутри | это эндпоинт, не сервис |
| UI | статика | не сервис |

## 4. Ограничение, которое разбиение НЕ снимает

Ядро SQS держит очередь в памяти одного пода (`globals.go` `SyncQueues`,
`redis.go` `LoadAllQueues`). «Не монолит» ≠ «масштабируется»: пока хранилище не
вынесено наружу (чтение тоже из Redis, либо иной сторедж, либо шардирование),
data-plane всё равно одиночка. Это отдельный, более важный вопрос — решать до
набора тенантов.

## 5. Размещение IoT (для полноты картины)

- К IoT внешний доступ нужен по определению (устройства). Managed-шлюз в цепочке
  IoT неизбежен.
- Но: телеметрия — мелкие MQTT-сообщения, для них критичен только разрыв wss ~150 с
  (лечится переподключением — уже реализовано в IoT).
- Большие payload'ы от устройств через MQTT-шлюз **не пускать**: лимит размера,
  дробление на уровне протокола, либо приём крупных данных на ВМ с вытягиванием
  кластером (схема drhider).
- IoT переделывается с нуля — не монолитом: bridge (MQTT), consumer (→storage),
  API отдельными сервисами.

## 6. Открытые вопросы (ждут решений)

1. Домен и сертификат для публичной точки SQS на ВМ.
2. Есть ли клиенты без явного `endpoint_url` (влияет на внешние `QueueUrl`).
3. Вынос хранилища data-plane (главный стратегический вопрос) — когда начинаем.
4. Крупные тела у IoT-устройств нужны или только мелкая телеметрия.

## 7. Следующий шаг

Подготовить развёртывание SQS на ВМ: разбиение на data-plane и control-plane,
nginx с правильным MTU/keep-alive/TLS, внешние `QueueUrl`. Старт — по команде
владельца.