"Короткие тезисы по стриму о Kafka от Монса Монс, он же Владимир Перепелица - огромный спец в распределенных технологиях и архитектурном ""харде"". Один из авторов Tarantool и VK S3, на котором мы строим свои Лейкхаусы. Тезисы, которые выписал себе по ходу стрима о Кафке, НАТСе, очередеях и стриминге данных. Когда внедряем Kafka 1️⃣ Kafka - Commodity инструмент для работы с потоками данных. Если нужна СУБД, берешь Postgres, если нужен стрим, берешь Kafka. 2️⃣ Kafka добавляет в данные измерение времени. В СУБД как правило - текущий снапшот данных. В Кафке автоматически и почти бесплатно генерируются истории изменений, которые потом может прочитать любой потребитель, а не только тот, кто их генерировал. 3️⃣ Идеальный сценарий работы для Kafka - генерируем поток данных или лог изменений состояний, не зная заранее, кому и зачем он может понадобиться. О движках 1️⃣ Kafka 4.x - переход на KRaft с Zookeeper. Отныне эта опция по умолчанию. 2️⃣ KRaft лучше и стабильнее, так как все данные и метаданные о топиках, консьюмерах хранятся в одной системе а не двух. Не тратим время на согласование из системы в систему и нет риска, что данные и метаданные в какой-то момент разъедутся. 3️⃣ Граница между движком очереди и движком стрима практически стерта сейчас. Стримы умеют в семантику очереди, очереди умеют в стримы. О растянутых между ЦОД кластерах 1️⃣ На расстоянии между ЦОД в десятки милисекунд синхронные транзакции работают хорошо. Этого достаточно чтобы сходить туда-обратно и подтвердить, что данные зафиксированы. 2️⃣ Проблема с синхронными транзакциями начнется когда и если на один пользовательский запрос мы начинаем тратить 10-50 транзакций. Это неверная архитектура приложения. Так делать не надо. 3️⃣ Правильный путь - делаем свои 10-50 изменений в приложении и в конце подтверждаем все одной распределенной транзакцией. 4️⃣ Альтернатива - садим в соседний ЦОД а-синхронную реплику и смиряемся с тем фактом, что некоторые данные при плохом раскладе мы моежм потерять Запись стрима можно посмотреть здесь Архитектор Данных"