Comments 6
Выглядит так что основной причиной использовать микросервисы в данном случае послужило то, что на проект ресурсы были выделены "на сдачу": с разными "стекам" и пришлось как то "выкручиваться".
Причина, конечно, не основная, но весомая.
Но если посмотреть на это позитивно, кажется неплохо, если появляется возможность в разработке отталкиваться от сильных инженеров, отлично знающих предметную область, а не от языка программирования/платформы/технологии, которые «нужно» использовать.
Но если посмотреть на это позитивно, кажется неплохо, если появляется возможность в разработке отталкиваться от сильных инженеров, отлично знающих предметную область, а не от языка программирования/платформы/технологии, которые «нужно» использовать.
S3 отлично позволяет хранить данные, но не даёт возможности выполнять эффективные поисковые запросы
а возможностей Amazon Athena недостаточно?
Спасибо за статью!
Как вы решаете проблему, когда вам надо добавить запись в БД и по завершении транзакции отправить сообщение в Kafka. Если транзакция завершится и система упадет, то сообщение не будет отправлено. Если отправлять сообщение до завершения транзакции, то она может тоже не пройти и у вас появится сообщение о несуществующей записи в БД.
Я конечно понимаю, что в запись в БД можно добавить флаг о том что сообщение еще на отправлено, завершить транзакцию, отправить сообщение и еще одной транзакцией выставить флаг, что сообщение отправлено. При запуске системы сканировать записи и отправлять сообщения для всех записей у которых нет флага об отправленном сообщении. В худшем случае будет двойная отправка сообщения (at least once).
Но это трудоемко. Для каждой сущности в большом приложении очень затратно описывать такой сложный воркфлоу. Плюс двойная запись на каждую запись может в конце концов ударить по перформансу.
Сталкивались ли вы с такими проблемами и как их решали?
Как вы решаете проблему, когда вам надо добавить запись в БД и по завершении транзакции отправить сообщение в Kafka. Если транзакция завершится и система упадет, то сообщение не будет отправлено. Если отправлять сообщение до завершения транзакции, то она может тоже не пройти и у вас появится сообщение о несуществующей записи в БД.
Я конечно понимаю, что в запись в БД можно добавить флаг о том что сообщение еще на отправлено, завершить транзакцию, отправить сообщение и еще одной транзакцией выставить флаг, что сообщение отправлено. При запуске системы сканировать записи и отправлять сообщения для всех записей у которых нет флага об отправленном сообщении. В худшем случае будет двойная отправка сообщения (at least once).
Но это трудоемко. Для каждой сущности в большом приложении очень затратно описывать такой сложный воркфлоу. Плюс двойная запись на каждую запись может в конце концов ударить по перформансу.
Сталкивались ли вы с такими проблемами и как их решали?
Sign up to leave a comment.
Строим распредёленное реактивное приложение и решаем задачи согласованности