---
# Агент: Claude Opus 4.6 | SQS Operator Planning

## Контекст
Пользователь попросил создать managed SQS-совместимый сервис очередей для облачного провайдера.

## Анализ вариантов backend
1. **ElasticMQ** — Scala, 2.8k stars, persistence (H2), SQS API, native image (GraalVM), Apache-2.0, активная разработка (v1.7.1 — 2 дня назад). ПОБЕДИТЕЛЬ.
2. **GoAWS** — Go, 834 stars, НЕТ persistence, только in-memory. Не production.
3. **LocalStack** — Python, 56k stars, эмуляция всего AWS. Избыточно.

## Анализ архитектуры
- **Вариант A (инстанс на тенанта)** — выбран. Изоляция, отказоустойчивость, ~30MB RAM idle.
- **Вариант B (shared)** — отклонён: "если наебнётся — то у всех".

## Ключевые решения
- Routing: path-based `sqs.kube5s.ru/sqs/{tenant}/` (не subdomain — не нужен wildcard DNS)
- Auth: Bearer token (существующий), абстрагирован для замены на ЛК
- Namespace: `sless-fn-{tenant}` (уже создаётся для serverless функций)
- Config: `SQS_EXTERNAL_HOST` — настраиваемый, для смены при деплое в облако
- DNS: создана A-запись `sqs.kube5s.ru` → 185.247.187.147

## Результат
Создан подробный план `doc/sqs-operator-plan.md` — 10 этапов, 9 файлов, готов для реализации Sonnet.