Комментарии 2
Заголовок не раскрыт вообще - что именно "не просто"? В статье описан стандартный inbox/outbox с очередью на таблице. В чём его сложность?
Стоит тег "высоконагруженные системы", но ничего не сказано о производительности outbox в целом и этого решения в частности. Какой поток сообщений выдерживает один инстанс постгри? Какая минимальная/максимальная задержка между отправкой и получением? Какая нагрузка на базу получается?
Ничего не сказано про очистку таблицы с очередью. При очень большом рейте публикации и удаления - vacuum будет доставлять ооочень много проблем.
А ещё этот outbox, скорее всего, вряд ли кого-то устроит - тут не гарантии очерёдности. Т.е. если в одной очереди два последовательных изменения одной и той же сущности - второе изменение может отправиться в кафка раньше, чем первое. Чтобы была гарантия очерёдности и при том отказоустойчиво - нужен механизм leader election и на одну очередь должен приходиться ровно один консьюмер. И когда приходишь к этому - вот тут как раз начинаются танцы с бубном: нужно сделать чтобы перехват лидерства был максимально быстрым - иначе на деплоях всё встаёт. Как быть с очерёдностью и dlq? Что делать, если одно из сообщений почему-то не может быть опубликовано (например, не пролезает в кафку по размеру)? Как рассчитать размер пачки, чтобы публикация не упала по таймауту?
В общем всё самое интересное и сложное как раз и не раскрыто (и, похоже, не реализовано) :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Возможно, Transactional Outbox не так уж и прост?