sless/doc/thinking/2026-04-07.md

---

Агент: 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.