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