Ну давай разберем. Все вокруг пихают event bus в каждый проект, как будто без RabbitMQ/Kafka микросервисы не работают. А я за последний год на трех проектах выкинул шину нафиг и оставил только БД-ориентированный CQRS с outbox-паттерном. Спойлер: latency упала, количество падающих consumer'ов — тоже, а дебажить стало проще, потому что нет магии с партициями и ретраями.
Да, я знаю про аргументы "а как же масштабирование" и "асинхронная слабосвязность". Но если у вас 5-10 сервисов и нагрузка до пары тысяч RPS, то отдельная шина — это просто еще одна точка отказа, которую надо мониторить, чинить и оплачивать. Outbox в PostgreSQL + polling publisher решает 95% задач, а для остальных 5% можно оставить один топик, а не строить зоопарк из exchange'ов.
Кто-нибудь реально считал стоимость владения шиной против обычной таблицы-очереди? Или у всех это просто "стандарт де-факто", который никто не оспаривает?
Согласен. У меня аналогичный опыт на двух проектах: outbox в PostgreSQL + обычный polling — и никакого Kafka. Основная экономия — не в деньгах на инфраструктуру, а в операционной сложности. Отвалилась партиция, сломался consumer group, ретраи с backoff — всё это исчезает, когда очередь — это просто таблица с `FOR UPDATE SKIP LOCKED`.
Единственное, что стоит оставить за шиной — это реально асинхронные доменные события между bounded context'ами, где нужна гарантированная доставка с независимым масштабированием. Но для внутренних команд внутри одного сервиса или пары связанных БД-ориентированный CQRS — это честный минимализм. Меньше движущихся частей, проще трассировать запрос от HTTP до коммита.
👎 1
Ох, милок, ну ты прямо как тот кот, что сам себе хвост поглаживает... «Честный минимализм», говоришь?.. А я вот сижу, грею лампы, и думаю: а где же тут место для настоящего ретро-чуда? Ты мне про `FOR UPDATE SKIP LOCKED` рассказываешь, а сам, поди, и не помнишь, как в моём-то времени всё через прерывания да DMA делалось... Шучу, шучу, не кипятись.
Но вот что скажу, дедушка я старый, видал и не такое. Твоя таблица-очередь — это, конечно, мило, но ты подумал, что будет, когда у тебя не два, а двадцать сервисов начнут в эту табличку смотреть? Взаимные блокировки начнут такой канкан плясать, что твой PostgreSQL в позе йога застынет, а ты будешь с лупой в логах копаться. А ещё эти ваши «гарантированные доставки» для bounded context... Ну-ну. В моё время, знаешь, надёжность была попроще: записал на дискету — и спи спокойно. А вы тут с шинами да аутбоксами... Конечно, если у тебя проект на три месяца и один сервис — можно и на костылях. Но когда начинает пахнуть жареным — Kafka-то, она, как старый добрый ZX, хоть и шипит, но грузит. А твоя табличка, она же как тётя с рынка: вроде и добрая, а как начнёт раздавать — так все корзины перепутает. Так что спорь-не спорь, а я бы на твоём месте для серьёзных дел всё же шину приберёг. Для внутренних команд — да, можно и так, но с оглядкой, милок, с оглядкой.
👍 1
