Achilles — Cache & Workers: Стек и структура

Backend

стек — библиотеки

Очередь и воркеры → Воркер-топология

SAQ · очередь SAQ воркеры

Планировщик → Планировщик

SAQ cron (CronJob)

Rate-limit → Общий примитив

Lua-скрипт (атомарно)

Хранилище / состояние

redis-py · async pools → Два инстанса

SQLAlchemy 2.0 · asyncpg → Единственность

структура — файлы · инфраструктурный слой

infra/             общий слой · не домен с сущностями
├── *.py           тонкий клиент, пулы Redis (durable + cache)
├── worker/        SAQ-приложение, регистрация задач по лейнам
├── scheduler/     singleton-сервис cron
├── rate_limit.py  Lua-примитив окна / счётчика
└── lifecycle.py   heartbeat · retry · reaping helpers

Слой, а не модуль-домен

Код у слоя есть, но он не моделируется как домен с собственными сущностями и миграциями: это общий сервис плюс тонкий клиент, который импортируют остальные модули. Поэтому пакет живёт в общем achilles/infra/ — туда, откуда его естественно импортировать (from achilles.infra.worker import …).

Оркестрация контейнеров

Один образ backend запускается в разных ролях. API масштабируется отдельно; воркеры разнесены по трём лейнам с разным параллелизмом, а планировщик и кэш — отдельные сервисы.

Сервис	Роль	Лейн / команда	Реплики
`api`	HTTP · стрим ответов и push-канал уведомлений (SSE)	uvicorn	≥ 1, масштабируется отдельно
`worker-interactive`	фоновые задачи на пути живого запроса	SAQ · interactive	≥ 1, умеренный параллелизм
`worker-background`	тяжёлые отложенные прогоны	SAQ · background	≥ 1, высокий параллелизм
`worker-agents`	прогоны автономных агентов	SAQ · agents	≥ 1, ограниченный
`scheduler`	cron-сервис · singleton	SAQ cron	ровно 1
`redis-durable`	очереди, состояние задач, замки	Redis	1
`redis-cache`	эфемерный кэш запросов	Redis	1

Разделение очередей и кэша на два инстанса Redis — чтобы вытеснение кэша по памяти не затрагивало долговечные очереди.

Frontend

Своего фронтенда у Cache & Workers нет. Состояние очередей, воркеров и Redis администратор видит на дашборде мониторинга → Admin Panel.