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

Да, онлайн-трансляцию мы сможем сделать.
Докладчики из Европы и даже США есть.

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

Отлично, спасибо за информацию

Подскажи плиз по такой теме: Делаем проект, где забираются данные из кафки, дополняются существующими данными и отправляются дальше. Автор проекта реализовал базовый концепт так, что данные из кафки обрабатываются один за одним, все эвенты ждут пока в один эвент не добавятся все нужные данные через http API-вызовы, если вызов фейлится то в бесконечном цикле вызывается заново - блокирующий режим. По мне это какая-то дебильная концепция:
1. блокирующий режим
2. апи-вызовы по текстовому протоколу.
Нужно обрабатывать несколько тысяч эвентов в секунду. Я озвучил мнение, что такая система ущербная и не будет работать. Можете подсказать насколько прав или нет, а то экспертизы по хайлоаду мало, но и херню делать не хочется :)

> дебильная концепция

в точку

> в бесконечном цикле вызывается заново

как минимум нужен разумный лимит (3-5 попыток) и потом переходить к следующему

в любом случае в однопоточном режиме вы объективно упретесь в какой-то потолок

> как минимум нужен разумный лимит (3-5 попыток) и потом переходить к следующему

ну там вроде че-то подразумевается, как=ая-то стратегия)

у меня возникли вопросы, существуют ли случаи, что в высоконагруженных системах делают блокирующий режим для чего-нибудь. И насколько приемлемым является использование http api вызовов. Я посмотрел что многие системы хранения данных используют свой протокол поверх tcp

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

есть события с кодами 1, 2, 3
2 и 3 не должны отправляться, если не был отправлен 1

спасибо

А как насчет апи вызовов и хттп? избегать если есть возмонжность?

но тут нужна логика, чтобы фейлить цепочку событий

это вы про последовательность?

saga..почитайте, может вам подойдет

Спасибо

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

Спасибо, что проявили интерес. Задача такая. В микросервисной архитектуре происходят пользовательские события, н-р логин, регистрация, изменение данных. Эти события нужно доставлять в систему аналитики. Микросервисы ничего не знают про эту систему, они отправляют данные о событиях в кафку. Соответственно события независимые, т.е. понятно, что обычно происходит регистрация, а уже потом изменение данных н-р, но сейчас последовательность не важна. Чтобы система аналитики могла работать с эвентом, его нужно обогатить пользовательской информацией, которую достают через http API-call.
Текущая реализация такая что, есть один большой сервис, который:
- забирает событие из кафки [Обработка других событий блокируется, т.к. нужно в кафку закоммитить что эвент прочитан, это происходит только когда успешно завершится его обработка]
- лезет в redis-кэш за пользовательскими данными [Если данных не хватает, делается API-call, и результат складывается в redis. Вопрос устаревания кэша решается тем, что если пользовательские данные изменились, должен быть обработан кафка-эвент, откуда берутся новые значения и обновляется кэш. Если API-call падает, то происходит его перезапуск. Пока неясно, сколько раз автор планирует его перезапускать. Но в качестве примера подобного успешного решения он приводит другой свой проект с функцией retryForever, где delay между ретраями начинается с 15 сек и в максимуме достигает 2 мин]
- насыщает событие,
- отправляет в аналитику.

Http между сервисами используется вовсю. Помимо всяких самодельных JSONRPC/SOAP/GraphQL он применяется и для работы с "общеупотребительными" движками: RabbitMQ, Clickhouse и т.п. Про Кафку не помню, но не исключено, что и там.

Другое дело, что это часто HTTP/2 или 3, уже допиленные для быстрой многопоточной работы.