Промпт для Opus — анализ архитектуры shared-sqs (2026-10-05)

Назначение: дать модели Opus контекст и точный список файлов для чтения, чтобы она проанализировала архитектуру shared-sqs и выдала идеи архитектуры (в т.ч. «КРАКО» — критический разбор архитектуры) без чтения лишних файлов.

ЗАДАЧА

Проанализируй архитектуру сервиса shared-sqs (SQS-совместимая очередь, Go, мультитенантная, форк GoAWS) и выдай:

Критический разбор архитектуры (КРАКО) — слабые и сильные места, риски, узкие места, что мешает назвать сервис готовым к продакшну.
Идеи по архитектуре — как довести сервис до production-ready: приоритизированный список доработок (P0/P1/P2) с обоснованием.

Не меняй код. Только читай и анализируй.

ЧТО ЧИТАТЬ (allowlist — ТОЛЬКО эти файлы, ничего больше)

Точка входа и роутинг:

app/cmd/goaws.go
app/cmd/seed.go
app/router/router.go

Конфигурация:

app/conf/config.go
app/conf/goaws.yaml

SQS-реализация (ядро):

app/gosqs/gosqs.go
app/gosqs/receive_message.go
app/gosqs/send_message.go
app/gosqs/create_queue.go
app/gosqs/validation.go
app/gosqs/tenant_helpers.go

Аутентификация / изоляция тенантов:

app/auth/auth_middleware.go
app/auth/jwt.go
app/auth/cache.go
app/tenant/tenant_store.go

Модели данных:

app/models/models.go
app/models/constants.go
app/models/globals.go

Персистентность:

app/persistence/redis.go

Биллинг и метрики:

app/billing/billing.go
app/metrics/metrics.go

Admin API:

app/admin/admin.go

Интерфейсы:

app/interfaces/interfaces.go

Документация (для контекста состояния):

README.md
doc/architecture/tenant-isolation.md
doc/billing-and-metrics.md
doc/byoc-credentials.md
HANDOFF-NEW-CHAT.md

⛔ ГДЕ НЕ ЛАЗИТЬ

Не читать doc/legacy/** (исторический план, старые решения — устарели).
Не читать deployments/** (легаси k8s/helm).
Не читать doc/thinking/nubes-* (сетевые тикеты платформы — отдельная задача, не относится к разбору архитектуры кода).
Не читать тесты *_test.go — они нужны только как сигнал «что покрыто»; для анализа архитектуры достаточно факта наличия из списка app/gosqs/*.
Не искать файлы за пределами перечисленного списка.

КЛЮЧЕВОЙ КОНТЕКСТ (факты, которые уже установлены — не перепроверять с нуля)

Стек: Go 1.23, gorilla/mux v1.8.0, redis/go-redis/v9, lib/pq, prometheus/client_golang. Сервис — один Go-бинарник.
Состояние: прод v0.1.35, все тесты зелёные, нагрузка 168 591 операция без сервисных ошибок. НО есть известные открытые вопросы (ниже).
Персистентность: Redis write-through cache. Память — источник правды для чтения; Redis — для восстановления после рестарта. Записи в Redis асинхронные (кроме DeleteMessagePersist — синхронно).
Изоляция тенантов: очередь хранится по ключу {AccessKey}:{queueName}; TenantStore с тремя индексами (byID, byAccessKey, byEmail).
JWT-валидация: подпись НЕ проверяется (trusted perimeter) — только структура + exp + PingNubesAPI() (проверка token через API Gateway).
Биллинг: асинхронная запись в PostgreSQL (таблица sqs_usage_records), опционально (включается при BILLING_PG_HOST).
Внешняя проблема (НЕ код, на анализ кода не влияет): периодические сетевые таймауты ~31–33с на внешнем шлюзе Nubes + MSS-баг для больших тел. Разобрано в тикете — это задача платформы, не кода.

ИЗВЕСТНЫЕ ОТКРЫТЫЕ ВОПРОСЫ (кандидаты в «доделать» — проверь их актуальность по коду)

BYOC-credentials — backend CreateFixed есть, но Admin API/UI (POST /admin/tenants с произвольными ключами) помечен TODO.
Подпись JWT не проверяется — насколько это приемлемо для multi-tenant прод-сервиса, или нужно усилить.
Дрейф доков — версии в README/Makefile/HANDOFF не всегда совпадают.
Легаси — невычищенные следы старого k8s/helm-деплоя и SNS.

ФОРМАТ ОТВЕТА

КРАКО — короткий критический разбор: что хорошо, что плохо, главные риски (по коду, а не по платформе).
Приоритизированный план доработок (P0/P1/P2), с указанием конкретных файлов и сути правки.
Список противоречий/несоответствий между доками и кодом, если найдёшь.

6.2 KiB Raw Blame History