Спасибо за интересное замечание. Знаешь ли ты какие есть недостатки у этого подхода с использованием, например, MS Exchange? Поправь или дополни пожалуйста, если где буду не прав:
Время приёма сообщения может варьироваться в зависимости от настроек батчинга, т.е. например через 5 секунд от времени отправки.
Производительность самого протокола достаточно лимитированная, из источников в интернете ~10.
В отличие от Message Queue, где автоматически реализованы peek-lock/иные механизмы, в MS Exchange нам придётся реализовывать всё самим?
Не развернёшь мысль пожалуйста? Автор комментария имел в виду, что даже используя ключи идемпотентности, 500 ошибка может также означать риски нарушения самой идемпотентности. В таком случае, у нас появляется большая проблема в валидации текущего состояния.
Например, мы отправляем сообщение группе людей из 3 человек, двум сообщение пришло, а одному нет из-за ошибки. Что должно произойти при следующем запросе на отправку этого же сообщения. Видимо это зависит от гарантий на стороне сервиса и имплементации идемпотетности сервиса, и это всегда стоит иметь в виду.
Абсолютно верно. Поэтому я говорю о важности идемпотентности — повторный вызов сервиса не должен приводить к дубликатам писем. С другой стороны, даже если внешний сервис не предоставляет никаких ключей идемпотентности в своих API, 500 ошибка скорее идентифицирует некорректное поведение и провал запрошенной операции — что говорит в пользу Retry.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Спасибо за интересное замечание. Знаешь ли ты какие есть недостатки у этого подхода с использованием, например, MS Exchange? Поправь или дополни пожалуйста, если где буду не прав:
Время приёма сообщения может варьироваться в зависимости от настроек батчинга, т.е. например через 5 секунд от времени отправки.
Производительность самого протокола достаточно лимитированная, из источников в интернете ~10.
В отличие от Message Queue, где автоматически реализованы peek-lock/иные механизмы, в MS Exchange нам придётся реализовывать всё самим?
Не развернёшь мысль пожалуйста? Автор комментария имел в виду, что даже используя ключи идемпотентности, 500 ошибка может также означать риски нарушения самой идемпотентности. В таком случае, у нас появляется большая проблема в валидации текущего состояния.
Например, мы отправляем сообщение группе людей из 3 человек, двум сообщение пришло, а одному нет из-за ошибки. Что должно произойти при следующем запросе на отправку этого же сообщения. Видимо это зависит от гарантий на стороне сервиса и имплементации идемпотетности сервиса, и это всегда стоит иметь в виду.
Абсолютно верно. Поэтому я говорю о важности идемпотентности — повторный вызов сервиса не должен приводить к дубликатам писем. С другой стороны, даже если внешний сервис не предоставляет никаких ключей идемпотентности в своих API, 500 ошибка скорее идентифицирует некорректное поведение и провал запрошенной операции — что говорит в пользу Retry.