Здравствуйте, Cyberax, Вы писали:

C>Не гарантируют. В случае падений SQS сообщения ещё как теряются, хотя они в последнее время исправились и падать почти перестали.
У меня первый проект с sqs стартовал года 4 назад. Уже более 2х лет в проде. Через sqs идут сотни тысяч(если не миллионы) сообщений в месяц. Ни единого нарекания на sqs за все это время. Что я не так делал?

C>Аж 25% скидки за последний месяц. Прямо как санкции против Северной Кореи по своей жестокости.
Еще раз повторюсь,. ты упорно демонстрируешь неумение читать. Просто дофига бизнесов с этим ок, его все устраивает и они прекрасно понимают что велосипеды будут стоить гораздо дороже.

C>Именно так. И никакие Tibco не дадут существенно лучший SLA, потому нечего на него кивать.
Я бы так не обобщал, ну да ладно.

C>У меня есть данные от нескольких очень крупных падений Oracle, с многомиллионными убытками. Во всех случаях Oracle не заплатил напрямую ничего. Про Tibco аналогично слышал из первых рук, но сам не присутствовал.
Даже опуская выделенное, это ОБС.

C>Что она даст, если критические компоненты не работают? Куда будет disaster recovery, если состояние системы неопределенное из-за того, что очередь сообщений скопытилась?
Очевидно, что развернет критические компоненты в другом регионе(клауде) и начнет процесить сообщения из резервной очереди, запись в которую идет синхронно с записью в основную (или с небольшим лагом, ок).

C>В моём примере очередь распухает н е из-за дубликатов, а из-за того, что уникальные обращения перестают обрабатываться.
Давай я процитирую

Автор: Cyberax
Дата: 16.08.17

тебя же, в этом же треде:

Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает.

Ты уж сам определись, какие сценарии мы рассматриваем а потом озвучивай их консистентно, ок?

C>Как это будет выглядеть на уровне API для клиентов?
Я уверен ты и сам прекрасно сможешь спроектировать REST API endpoint. И может быть даже реализовать

I>>Еще как поможет, разгребет потихоньку если входной поток ограничить как я описал выше.
C>А нафиг он тогда нужен? Не проще ли использовать синхронные вызовы?
Иногда проще, иногда — нет. Типичный сценарий — пиковые нагрузки. Погугли что это такое и чем они отличаются от stable. Еще один сценарий долгоиграющие операции, например транскодинг видео. Перегонять 2х часовую порнуху серию игры престолов в формат для айпада синхронно — наверное не самая лучшая идея. Если ты не сталкивался с подобными кейсами — то это совершенно не означает, что их не бывает.

C>А бэкэнд всё равно должен быть надёжен, так как иначе никакие 100500 девяток в SLA не помогут.
Кому должен, зачем должен и главное кто будет все это оплачивать?

I>>Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).
C>В случае с синхронным вызовом состояние системы не хранится в сетевом соединении, кроме как для статуса последнего запроса.

Еще раз повторюсь:

Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что. Это очень смелое заявление. Не, я понимаю у тебя оно с кнопкой 'checkout shopping bag' не взлетело по каким-то причинам, но нельзя же все задачи программирования натягивать на кнопку checkout?