В этом и сила так сказать.

Интересное определение.

Я думал жто про то, что они равны, как и писал выше.

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

Пойду учиться дальше.

Да, равны. И могут взаимодействовать «напрямую».

Но, очевидно, это не подразумевает, что между узлами брошен отдельный провод на каждую пару узлов 🙂

Соответственно, есть некоторое количество уровней (мы, я надеюсь, говорим про прикладное взаимодействие сервисов, а не сетевое взаимодействие). Поэтому ничему не противоречит поставить Кафку в качестве одного из уровней.

А продьюсер и консьюмер - интерфейс для обмена сообщениями между пирами.

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

Наверное, синхронизировать не требуется, но вот выждать какой-то таймаут и сказать, что сообщение потерялось — да.

На самом деле, такая архитектура будет похоже на service mesh, но не по http, а через Kafka (т.е. асинхронно и персистентно).

Проблемы аналогичные head of line blocking тоже появятся из-за ордеринга

Ну, как и в (практически) любой распределённой системе вводим понятие версии (или эпохи) и решаем так все проблемы ордеринга 🙂

Я не спорю с ничем вышеописанным :) сначала было высказывание что Кафка поддерживает p2p. Сама Кафка подразумевает pubsub в разных вариациях, а то что мы можем сделать p2p на уровне приложения - это да.

Или я что-то не знаю

Всё так. 🙂

Собственно, вот тут ☝️и зафиксирована основная мысль. Разве что на уровне Кафки это может быть организовано по-разному. Тут выше предлагали сделать по топику на каждое ребро, но обычно так не делают, из-за квадратичного роста. На мой взляд оптимальным (при условии, что нам по какой-то причине нужна архитектура a la p2p) было бы делать по одному топику на каждый сервис для приёма, а отправлять события в топик сервиса, с которым хотим взаимодействовать.

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

Там еще local store тоже к таске привязан