думаю начать знакомство стоит с этого, если нету знаний

значит решения всего 2 -
1) 2 площадки, по 1 кластеру и между ними реплика
2) 1 площадка с 1 кластером и все, вторая площадка не задействована

спасибо

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

окей, пойду изучать теорию. спасибо

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

ну, я на всякий случай

)

если это отдельные AZ (домены отказа) с понятной bandwidth/latency между ними.. ну. ок... можно попробовать )

вы недооцениваете некоторых архитекторов и их идеи

+

вообще интересно что возник вопрос про кафку кросдц после того как решили кросдц с остальными компонентами

что меня смущает в кроссдц кафке:
1) нужно сразу принять истину что будет или быстро (не ждем isr с удалённого дц) или отказоустойчиво (ждем isr со второго дц)
2) кастомный партишинер для записи (мы должны гарантировать что пишем локально)
3) кастомные настройки для чтения (мы должны как-то сказать под какие партиции мы подписываемся чтобы случайно не подписаться на удаленную, читать ведь ожидаем локальные)
4) топик с комитами всё равно надо размазывать по обоим дц, иначе будет боль
5) я до сих пор не видел что в этому случае делать с zookeeper (он то требует кворум для выбора мастера, следовательно как собрать 50%+1 голос при выпадении одного датацентра я вот так с ходу и не скажу)

причем пятый пункт никак не решается отказом от зукипера на свой велосипед
так как если нету кворума, то получаем сплит-брейн

касательно п.5 - делаем кафку с ЗК в 3 ДЦ и офигеваем.

(в плохом смысле)

ну тут было про 2 =) с тремя каждый может

третий нужен только чтобы один процесс ЗК запустить, подойдет что угодно

если вы хотите читать только в локальную кафку и писать только в локальную кафку, может быть сделать не общий кластер, а реплику между отдельными кластерами?