Господа кложуристы. А вот подскажите по микросервисам и идемпотентности. Написал я сервис. Берет сообщение из очереди, делает работу и апдейтит базу. если 2) permanent fail - логгируется и апдейтит базу если 3) temporary fail -- логгируется 4) работа уже сделана -- тихо выходит. Во всех случаях сообщение удаляет (в 3 после неск. попыток) . Очередь служит только средством доставки. Постановщик заданий ставит задания в очередь, когда его дергают, до тех пор пока база не проапдейчена. решения принимаются на процессоре сообщений. afaik на уровне системы получилась такая себе стейт машина. Мне говорят плохо, потому как не идемпотентность. Переписал. Теперь мы возвращаем сообщение в очередь всегда, кроме случая 4 и 1. В том числе и на permanent fail. то есть пытаемся выполнить по несколько раз. зато f(f(x))==f(x) Мало того, что это неэффективно, так функционирование моего сервиса оказывается теперь завязанным на очередь, которая теперь должна решать вопросы ретраев плюс deduplication check (сообщения плодятся). смысл?

@andmed чет плохо врубился, что делает сервис. вопрос: а очередь со стейтом? Это типа RabbitMQ. Или без стейта? типа kafka

очередь должна быть тупой (как буратино), всмысле не иметь стейта и отвечать только за транспорт. все вопросы работы с очередью должны решать клиенты, которые читают очередь. Если очередь как кафка, то ничего не надо возвращать в очередь, т.к. клиент сам должен помнить с какого смещения читать очередь (последнее обработанное сообщение в очереди)

если база не проапдейчена, то клиент автоматом должен видеть, на каком сообщении застряла обработка.

вопрос в temporary failure? это sqs. в ней по умолчанию нет FIFO вообще. FIFO версия дает и deduplication check (за дополнительные деньги aws, да), но главное мы завязаны на конкретную имплементацию теперь (deduplication check в ней через metadata). в моем варианте если не можем проапдейтить сообщение мы могли бы внедрить counter и перепослать сообщение. теоретически здесь возможна проблема при многих воркерах: несколько сообщений с разными counter, но практически первое успешное завершение (или threshold по fail) проапдейтит базу и при обработке других сообщений мы сразу тихо выйдем.

потом это плохо скелится: речь об генерации thumbnail, а мы не picasa)