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

A>Я хотел предложить разобрать конкретный кейс и альтернативные реализации для одних и тех же требований — было бы интересно сравнить решение предлагаемое cyberax'ом против решения на очередях.
Ну давай попробуем, все равно проект заканчивается, скучаю.

Сценарий 1(несколько упрощенней чем в реальности)
Преподаватель загружает лекцию на сервер(S3 де факто) для того чтобы студенты могли ее просмотреть.
После загрузки надо
— проанализировать формат видео
— запустить транскодинг в необходимые форматы(mp4, aac)
— сгененировать thumbnails
— по окончанию всего что выше — отметить лекцию как новую и готовую к просмотру
— послать нотификацию студентам которые включены в соответсвующий курс
Все операции (транскодирование, thumbnails, нотификация) организована на сообщениях в очереди. Агрегация — в бд.

Сценарий 2
Преподававтель заходит на веб сайт и меняет  description к видео.
Изначально планировалось делать асинхронно через очереди, с обновлением кеша. Это было связано с тем что проектировался multiregional deployment и соотвсетвенно репликая БД во все регионы. По результатам тестов, это занимало до 10 минут, в среднем 2-3.
Но потом решили деплоиться в один регион и сделали синхронный вызов.

Сценарий 3
Студент заходит на страницу лекции. Надо послать соотвествующее сообщение для сбора статистики — какие видео популярны и так далее.
Сделано опять таки на очередях.

Сценарий 4(другой проект)
Имеется несколько сервисов, которые общаются друг с другом. Разрабатываются разными командами, деплоятся независимо друг от друга и достаточно внезапно, с даунтаймами. Коммуникация между командами плохая(разные компании, разные континенты). Тут Внедрение сервис баса сильно все упростило. Появилось полное tracebility коммуникации, формат сообщений валидируется сервис басом, retry полечил проблемы независимого деплоймента, dlq, помогло при траблшутинге, минорные изменения формата сообщений полечилось трансформацией на сервис басе и закончился пинг-понг между командами что "у нас все работает".