В случае если в момент времени после коммита транзакции и до записи в Kafka Broker произойдет: OOM Kill producer, падение broker, сетевые проблемы и т.п.
Проблема что запись в БД и Kafka не синхронизированы между собой. Из-за этого возможны 2 вида проблем:
Произошла запись в Kafka, но при комите транзакции в БД произошла ошибка. В итоге запись Kafka есть, а в БД нет.
Так как Kafka producer не отправляет сообщение сразу, а старается буфферизовать несколько сообщений для большей эффективности передачи данных, то может возникнуть ситуация, что транзакция в БД закомитилась, а сообщение в Kafka Broker так и не было доставлено. В итоге запись в БД есть, а сообщения в Kafka нет
Мне кажется вы заблуждаетесь в терминологии. Вы называете конкретный инструмент OpenTelemetry - идеологией. Хотя в документации прямо написано что это лишь конкретный механизм. Если говорить про концепцию, то называть это следует Observability.
Поэтому люди делают справедливое замечание, что название вашей статьи никак не отражает содержания.
В статье пример, где источник данных - это REST Endpoint по созданию order.
Слабое место, что это работает только в случае, если Kafka является источником сообщений.
В случае если в момент времени после коммита транзакции и до записи в Kafka Broker произойдет: OOM Kill producer, падение broker, сетевые проблемы и т.п.
Вы сами приводите пример, когда гарантия at least once не выполняется. Есть категория систем для которых это не позволительно.
Проблема что запись в БД и Kafka не синхронизированы между собой. Из-за этого возможны 2 вида проблем:
Произошла запись в Kafka, но при комите транзакции в БД произошла ошибка. В итоге запись Kafka есть, а в БД нет.
Так как Kafka producer не отправляет сообщение сразу, а старается буфферизовать несколько сообщений для большей эффективности передачи данных, то может возникнуть ситуация, что транзакция в БД закомитилась, а сообщение в Kafka Broker так и не было доставлено. В итоге запись в БД есть, а сообщения в Kafka нет
Данный паттерн стремиться решить эти проблемы
Мне кажется вы заблуждаетесь в терминологии. Вы называете конкретный инструмент OpenTelemetry - идеологией. Хотя в документации прямо написано что это лишь конкретный механизм. Если говорить про концепцию, то называть это следует Observability.
Поэтому люди делают справедливое замечание, что название вашей статьи никак не отражает содержания.
Давать изменять данные в БД с фронта не лучшая идея. У вас проблемы с безопасностью:
Кто угодно может добавлять/изменять данные в таблице рекордов.
Жаль, что у вас нулевое покрытие кода тестами. Тестировать реактивные системы это отдельная интересная тема, которую вы незаслуженно обошли стороной.
Ну или можно использовать образы LibericaJdk. У них есть образы jre-alpine (55 MB), и jre-alpine-musl (чуть меньше 50 MB).