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

I>Ломается, именно об этом и пишут в SLA. Поломается, бизнес недополучит прибыль, провайдер компенсирует(так или иначе). И отлично в огромном количестве бизнесов.
Почитай SLA на сервисы Амазона или аналогичных. Никто ничего компенсировать не будет.

C>>Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.
I>На уровне api gateway синтегрировав с мониторингом.
Ещё раз, мониторинг позволит (максимум) обнаружить аварийную ситуацию. Он не позволит её исправить.

Ну и вообще, как можно проектировать системы, которые по дизайну будут требовать ручного привода???

C>>Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?
I>Я уже несколько раз писал, читать, как я уже понял, ты не умеешь. Давай попробую зайти с другой стороны: по разному, в зависимости от конкретных требований.
Ну вот объясни. Требования я привёл.

I>Прикинь, в спецификациях вполне может быть написано: "потеря до Х% данных допустима". Пример — влегкую, допустим у тебя сайт flightradar24, который прямо в риал тайме слушает местоположжение самолетов(они могут бродкастить каждую секунду) и рисует это на веб странце.
Ну вот я и говорю — сообщения пригодны для fire-and-forget best effort вещей.

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

I>Мне вот интересно, ты и вправду считаешь покупателей подобных решений полными дибилами, которым продают полный неликвид на протяжении чуть ли не десятилетий,
Да, именно так я и считаю. И сколько раз уже на практике проверил.