EZRA — это постоянная очередь задач. Несколько сервисов пушат задачи, несколько воркеров забирают их и подтверждают выполнение. Каждая задача остаётся видимой и отслеживается, пока воркер не пометит её сделанной — никаких тихих потерь или fire-and-forget. Внутри SQLite и рантайм Erlang/OTP. Воркеры подключаются любым Redis-клиентом (сам Redis не нужен) на любом языке — никаких новых SDK.
Весь сервер — одна docker-команда. С любого компьютера, который видит порт, продюсер делает XADD, воркер — XREADGROUP с блокировкой, а после обработки — XACK. Язык любой: Python, Node.js, Go, Ruby, Java — просто укажи порт 42002 вместо Redis. Потребление на воркера — ~2 КБ, база ~20 МБ, пропускная способность 15–30 тыс. задач/сек на SSD и до 80 тыс. на NVMe.
Зачем это вообще? Почти в любом приложении надо что-то сделать вне запроса — отправить письмо, сгенерировать PDF. Хочется вернуть ответ сразу, обработать в фоне, повторить при ошибке и не потерять при перезапуске. Готовые очереди (Kafka, RabbitMQ) часто избыточны для обычных задач — кластеры, администрирование, привязка к облаку. В итоге многие делают всё в памяти и теряют работу. EZRA — лёгкая альтернатива: один бинарник, один SQLite-файл, любой Redis-клиент. Ни брокера, ни кластера.
Как это работает. EZRA говорит на RESP3 — том же протоколе, что Redis. Команды — из Redis Streams: XADD, XREADGROUP, XACK, XDEL. Остальные (GET, SET) возвращают ошибку — это не Redis. Жизненный цикл задачи: push → pop (in_flight) → ack (done) или nack (снова available, пока не кончатся попытки, потом dead). Задачи никогда не теряются. Если EZRA перезапускается, все in_flight сбрасываются в available до приёма новых задач. Это at-least-once delivery по замыслу.
Компромиссы очевидны. Одна нода — если машина упала, очередь недоступна. Данные — SQLite-файл, легко бэкапить. Нет exactly-once — задача может выполниться дважды, если видимость истекла до ack. Нет fanout, приоритетов, отложенных задач, транзакций между очередями. Рекомендованный лимит payload — 100 КБ. Выполненные задачи копятся, если не настроить retention.
Подойдёт для фоновых задач (почта, PDF, ресайз), полиглот-команд, ранних продуктов, где Kafka — перебор. Не подойдёт, если нужна высокая доступность, pub/sub, throughput выше SQLite или сложная маршрутизация на уровне брокера.
Установка — скачать бинарник (~20 МБ), запустить с флагом --data-dir. Сигнал SIGTERM — чистый shutdown. Для Elixir-разработчиков доступна интеграция внутри процесса без TCP.