(Бред какой-то - но код Ecto выглядит, что такое есть в коде)

А, разобрался, но ошибка весёлая. 🙂

Ситуация из тех, когда много лет не трогал ecto 🙂 И снова активно его используешь.

Хехе, главное разобрался

Ну напиши хоть объяснение :)

А что вы использовали для маппинга данных?

1. Чтобы горизонтально масштабировать, плюс так сложилось, что мне когда есть очередь проще понимать, что происходит в системе в целом чем когда рест апи. Может я какой-то испорченый :)
2. Читал гайд по практикам к RMQ там было сказано,  что очередь лагает если сгружать туда все поэтому желательно держать ее практически пустой всегда. Это не так?
3. Kafka мне говорили сложно в плане менеджмента и поддержки.  RMQ/NATS/Google Pub/Sub - примерно такие я слышал рекомендации.

> Читал гайд по практикам к RMQ там было сказано,  что очередь лагает если сгружать туда все поэтому желательно держать ее практически пустой всегда. Это не так?

не замечал

если на стороне потребителей не будет ограничений на приём, потребители будут захлёбываться в потоке. может, это имелось в виду? самому rmq в целом пофиг, ну до тех пор, пока он все ресурсы не выжрет, в таком ключе много что лагать может

Если у тебя один продьюсер, то ничего масштабировать не получится, он будет бутылочным горлышком
Если у тебя несколько продьюсеров, то гарантировать отсутствие дублей на стороне продьюсера будет очень сложно

Самый простой вариант — добавить гарантию того, что одно и то же сообщение попадёт в один и тот же консьюмер (например, шардирование) и, как сказал @maxlapshin , читать идемпотентно, запоминая прочитанные сообщения (не обязательно все, можно очищать старые запо

И вообще, зачем тут кролик. Сделать пулл модель — консьюмеры делают REST запрос в продьюсер когда они ничего не обрабатывают (или обработка вот-вот кончится), REST это совсем не дорого, особенно учитывая что практически любой http-клиент в наше время умеет держать соединение и инициировать его с tcp fast open

В таких задачах очевидно не идет разговор о скорости

Если нужон риалтайм - broadway нужон с kafka/sqs

Rabbit - это про бизнес

Вообще если бы я скрпил 1кк страниц и у меня 5% повторений было бы - я бы забил наверное

Идемпотентность обеспечивается на выходе из консьюмера когда пишешь в базу

https://www.cloudamqp.com/blog/2018-01-08-part2-rabbitmq-best-practice-for-high-performance.html

“eep your queue short (if possible)
To get optimal performance, keep queues as short as possible. Longer queues require more processing overhead. We recommend that queues always stay around 0 for optimal performance.”

я думаю, тут речь уже о каких-то огромных значениях. но, опять же, если так критична скорость обработки большого числа сообщений, возможно, rmq не лучший выбор под этот кейс. выше уже всё сказали на эту тему как раз..

Понял. Нет не критична скорость.

Один продюсер можно вертикально масштабировать + можно убирать из стейта уже обработанные данные которые прилетают обратно от консумиров, и не давать ему тем самым разростаться.