С кроликом я делаю так: 1. у тебя есть продюсеры. Те

Question

С кроликом я делаю так: 1. у тебя есть продюсеры. Те

кто кидают команды или ивенты. Они кладут сообщение в очередь (кворумы + лимит на количество сообщений в памяти в ноль что бы сразу на диск) или там эксчейндж из которого сообщения роутятся в очереди разных сервисов, и ждут publish confirms
2. у тебя есть консюмеры. Важно что бы одно сообщение было для одного консюмера. То есть если у тебя 2 сервиса - тебе надо что бы одно сообщение с ивентом попадало в 2 очереди, каждый для своего сервиса. Что бы оттуда они могли независимо акать все и там можно было настроить dead letter для ретраев и прочего.

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

Для упрощения допустим что у тебя есть ивенты которые публикуются раз в секунду. И на эти ивенты подписано 100 сервисов. Это значит что у нас уже 100 сообщений в секунду надо как-то прогонять через кролика. Это все еще не много для кролика, но вот это "умножение" очень быстро может в более-менее нагруженных системах привести к проблемам.

При этом мы не имеем истории. У тебя мол максимум что можно это "сервис зарегал свою очередь" и за счет этого можно какие-то гарантии доставки сделать. Если ты захочешь новый сервис поднять и обработать ивенты заново - то да ты пойдешь в кликхаус читать ивенты. И тогда вопрос - а нахер нам тогда кролик если мы изначально могли просто читать стрим из кликхауса? Мы так или иначе должны будем решать задачу "а как нам надежно читать оттуда и двигать курсоры, как ретеншены организовывать и т.д."

И как бы уже не так очевидно что сложнее. Поднять кафку или поддерживать это все...