Сейчас на рынке от джуна ждут, что он мидл.
От мидла ждут, что он сеньор помидор.
А от сеньора ждут, что он архитектор.
Поэтому пытаюсь потихоньку читать "айтишные" книжки. Дошёл до Брендана Бёрнса, «Распределённые системы. Паттерны проектирования», и там есть один архитектурный паттерн, про который редко пишут, но он вполне простой и называется Scatter / Gather.
Допустим тебе прилетает задача: спроектировать интеграцию, в которой нужно тянуть инфу сразу с пяти источников.
Самое очевидное, что приходит в голову: дёрнем каждую ручку по очереди.
Или какой-нибудь асинхрон с кафкой замутим.
А паттерн Scatter / Gather говорит нам: метнись кабанчиком. Только не к каждому по очереди, а ко всем сразу.
Scatter: Диспетчер разбрасывает запрос по всем пяти источникам одновременно.
Gather: и собирает ответы в кучу, склеивая в один результат.
Звучит, как изи катка. Но что, если один из пяти источников сегодня тупит?
Диспетчер не отдаст ответ, пока не дождётся вообще всех, так что вся система быстра ровно настолько, насколько быстр самый медленный. И чем больше источников надо подключить, тем выше шанс, что хоть один да затупит.
И вот тут у нас, как у архитектора, происходит выбор:
🐘 Ждать всех до последнего (тогда весь ответ упирается в самого медленного).
🦛 Ставить таймаут и собирать то, что успело прийти (тогда результат может быть неполным).
🐗 Решать заранее, что делать с «молчунами»: игнорировать, повторить запрос, подставить дефолтное значение.
У автора ответ один: не полагаться на единственный источник, а держать пару его копий про запас. Затупил основной, диспетчер тут же дёргает дублёра.
Только это работает, если источник твой. Если это внешняя система, которая тебе не принадлежит, придётся выбирать из трёх пунктов выше.
А у вас кабанчики бегают к своим источникам или к чужим? И как выкручиваетесь, когда внешняя система тупит?
IT АНАЛитика | Подписаться