⚙️ Куда она закатилась? Надежность. Продолжаем осмыслять.

☝️ Ты думал, что знаешь всё про архитектуру? Давай осмыслим её ещё раз!
Хотел бы осветить следующий доклад, на котором получилось присутствовать онлайн и задавать вопросы после.

Филипп Дельгядо - «Где искать надежность при взаимодействии сервисов?»
Какие реальные взаимодействия стоят за нарисованными квадратами и стрелками? Почему то что принято считается надежным by default?
Филипп предлагает задуматься над стандартными архитектурными паттернами. Разбирает их надежность. Исходя из опыта описывает различные сценарии что может произойти и как сделать лучше.

• Надежность
💻 ❌ Вдобавок к проблемам самого приложения и транспорта нужно помнить о проблемах с железом.
• Железный пример
Вводная:
Есть сервер. Живёт 55000 часов. Есть резервный. Узнаём, что сервер умер за 1 секунду. За 2 секунды можем восстановиться.
=>
Вероятность потери всех сообщений за эти 2 секунды - 1 раз в миллиард лет.☝️
• Железный пример + Приложение
Приложение падает каждый день из-за утечек памяти. Узнаём за 30 секунд(http таймаут). Вероятность потерять все сообщения за 30 секунд - 1 раз в 6 лет.
• +100 сервисов по 20 экземпляров
Взаимодействие каждый с каждым. 20 млн взаимодействий. Проблемы 4 раза в сутки. 🙁

• Взаимодействия
🤍 ⁉️ Yже давно запросы от клиента напрямую не ходят в сам сервис. Кто-то стоит посередине - api gateway, loadbalancer, service mash.
Если прошёл таймаут на обработку сообщения(клиенту нужен результат быстро или не нужен вообще), то сообщение уже не нужно обрабатывать. Такой наплыв сообщений лишним грузом повисает на плечах сервиса.
Получается, что хоть экземпляр сервиса и доступен, и service mash роутит на него запрос, но обработка уже явно займёт больше таймаута.
=>
• Нужно как минимум реализовывать механизм heartbeat - периодическая проверка, что экземпляр живой.
• И ещё лучше докрутить логику - если этот экземпляр отвечает за 20 миллисекунд вместо 10 в прошлый раз, пошлю запрос в другой. Это будет лучше, чем ожидать долгого ответа пускай от даже, вроде бы, живого экземпляра.

• Паттерны
➕Знакомая очередь посередине. Она должна развязать producer'а от consumer'а. Как бы не так!
➖Зависимости стали косвенными! Не понятно - consumer переключился на новую версию или нет!

Брокер должен знать про число партиций. Это легко не поменять.
Producer знает каким образом consumer хочет чтобы его данные партиционировались. Т.е. producer должен обладать информацией о внутренней реализации консьюмера, чтобы корректно сформировать события, отправляемые в топик.

Очень ценная мысль! В http не надо знать каким образом устроен получатель.
Упомянуты битвы в крупных компаниях про число партиций в топике, количеств топиков в целом.😣
=>
Приходит на помощь паттерн Transaction Inbox!
Вносим очередь в сам сервис, который и потребляет данные. Заход через его api.

Вывод:
К проектированию надежности стоит подходить со всей серьезностью. Продумывать архитектуру начиная с железа. Учитывать рост нагрузки, сбои. Переосмыслять знакомые паттерны. Смотреть, что лучше всего подойдёт для реализации именно твоих требований с тем техническим, финансовым, административным окружением, что у тебя есть сейчас.

Хочешь ещё разборов докладов? -> ⚡️
Насколько тебе легко работается с очередями?