SQS-service/doc/thinking/architecture-analysis-2026-10-08.md

Архитектурный анализ размещения и разбиения 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. Старт — по команде владельца.