Жесть конечно. Даже не представляю где человеку который этим занимается будет не скучно работать... апишки там пилить с микросервисами, с браузером бадаться =))
Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.
Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.
Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?
struct StatusField {
originaldata string
newdata string
isModified }
Особенно если апишка частично crudish... И все ради того что бы иметь один метод reservationRepo.save(reservation);
Пользуем миро для евент сторминга, описания архитектурных решений и коммуникаций между сервисами, описания всяких флоу и т.д. В рилтайме можно обсудить и подправить. Удобно.
Меня смутило то что кафка стримс инстанс будет скачивать весь топик и строить таблицу в пямяти. А если у меня очень очень много данных? Например заказы с десятков или сотен магазинов. Как делается холодный старт? Что произойдет при рестарте инстансов? Или при стандартном скейл ап/даун?
Ох как хочу посмотреть через пару лет на их кодовую базу без стандартных абстракций когда их же менеджеры не дадут им время на рефакторинг что бы внедрить их в будущем.
Понятно что абстрактную фабрику не нужно пихать на каждый чих, но какие претензии к репозитори/дао слою? Возврат к спагетти, который ни тестировать ни рефакторить нормально нельзя...
Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.
Сразу в любом проекте будет понятно из чего он состоит и куда смотреть в случае чего.
Я так представляю в скором времени у них что бы понять что тут в сервисе происходит нужно будет читать тысячи строк, вместо того что бы пройтись беглым взглядом по абстракциям и файликам.
Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Если это b2b то есть смысл регистрацию и вход делать отдельным приложением и просто редиректить на него. Хочешь микро-фронт, хочешь вообще отдельное приложение написанное на другом стеке тупо под любым веб-сервером.
А если зарегаться может любой то смысла большого нет. Всегда можно зарегаться и увидеть все приложение.
А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.
Рассказали обо всем кроме самой информации об автоматизации. Как оно работает? Какие инструменты используются? Кто решает, стала ли проблема блокером или можно продолжать спать?
Смотрю на наши проблемы в продакшене, и они настолько разные, что человеку тяжело понять что вообще пострадало в результате, и что теперь делать.
Мне 35 и глядя на уровень нынешних выпускников всяких курсов и даже выходцев университетов, мне работы хватит лет до 100...
Причем владельцы стартапов стареют вместе с нами, и также понимают что опыт это очень ценный актив. Поэтому пора перестать плакать а том что карьера программиста заканчивается в 30...
В принципе на бэкенде тоже самое и это кстати важно понимать. Если нет трейсинга, документации/ADR, то понять бизнес будет сложно. Теряется общая картина. И вот сидишь ты и смотришь на все эти месседжи и не понимаешь а какие вообще бизнес процессы тут протекают и что с этим всем делать.
Особенный ад это когда евенты в виде крада... reservationUpdated, listingEdited. Легче застрелиться чем поддерживать такую систему.
Вы правы. Уже 4 года варюсь в message driven/event driven и система все еще продолжает удивлять. От простых ритраев которые спасают и могут и проблемы сделать если нет idempotency, до спайков которые убивают http сервисы или базу потому что воркеры скейлятся намного быстрее и нужно делать circuit breaker и рейт лимиты.
Про параллельную обработку это вообще отдельная тема...
От построения тупого POC до системы которая будет реально работать как часы, как от земли до луны.
Последний раз 3 дня копал почему у нас воркер который работает с раббитом крашится, и месседж остается все время в head и все это повторяется и вообще ничего не может процесситься.
Готовлю статью на медиуме на эту тему. Оказалось для long running CPU bound job драйвер раббита для NODEJS не может отправить heartbeat и раббит закрывает соединение =)))
P.S.
Но справедливости ради нужно сказать, все таки эта архитектура необходима если вам важны данные и важно их процессить, и важно иметь возможность управлять нагрузкой и разделать ворклоады. Если же вы готовы терять реквесты если сервис лежит, и вам не важно что один клиент может повлиять но всех остальных, то может оно вам и не надо...
Насчет восстановления базы - интересный вопрос. Вряд ли тут есть генерное решение. Но в принципе можно к этому относиться как частному случаю ресета оффсета опредееленного консьюмера.
Если сама синхронизация очень тупая, в виде простых идемпотентных апсертов на стороне сабскрайберов, то все должно работать out of the box.
Если же вьюшки строятся сложнее (например мерж нескольких стримов или обогащение евентов синхронно (что не очень хорошо) в консьюмере, тут уже нужно конкретно по ситуации смотреть. Возможно что-то умнее придумать при помощи idempotencyId, timestamps, маппинга оффсета на стороне сабскрайбера с данными чтобы и написание умного рикавери процесса.
Есть конечно нюансы. Например в нашем случае используются топики, где храняться несколько месседжей на определенный _id (зависит от настроек топика кафки) и нужно иметь ввиду что когда будет идти восстановление, то в какой-то промежуток времени мы можем иметь во вьюшке не самые последние данные из тех что мы имеем.
Насколько я знаю, можно настроить топик хранить только последнюю копию документа монги.
Я люблю CQRS. В нашем легаси, как один из шагов в сторону мискросервисов, DDD, евентов + трушный CQRS, мы используем CDC. В нашем случае это Mongo + Kafka connector. И сабскрайберы подписываются на изменения определенных коллекций, и уже создают у себя нуные им вьюшки, в подходящщей базе данных и в подходящей структуре.
Тьфу тьфу работает стабильно и позволяет сделать анкаплинг сервисов и получить реальный профит.
Но нужно заранее думать о том как делать рикавери если что-то пошло не так. И если все делать правильно - рикавери сводится к рисету оффсета сабскрайбера на топик.
На функционал да, но данные будут неактуальными, это лишь скрытие проблемы. Что лучше при ошибке обновления данных - оставить то же значение или показать пустое значение / текст ошибки?
Это не сокрытие проблемы. Это часть анкаплинга и релаябилити. Как пример, автор изменил свое имя, и мы не проапдейтили статьи, потому сервис авторов изменил структуру событий и мы не может их обработать. Юзеру пофиг. Если имя обновится через час когда баг будет пофиксен, это равносильно тому что если бы бага не было с самого начало, а сам автор решил бы изменить свое имя на 1 час позже.
Все эти случаи должны обсуждаться с домейн экспертами. В критических случаях можно показывать возраст.
Вы когда на сайте банка заходите, и вам зашла зарплата, и вы сделали какие-то покупки, вам почти всегда показывают устаревшие данные.
А теперь представьте у банка проблема и один из их сервисов упал и его будут чинить сутки. Вы предпочтете видеть 0 или устаревшие данные с надписью - "Данные актуальны на ... и могут не содержать результаты последних операций"?
Никто не запрещает сделать простую обработку и возвращать частичные данные при отказе сервиса нижестоящего сервиса.
Вы мыслите как программист а не как домейн эксперт. В большинстве случаем старые данные намного ценнее странички с пустыми данными.
Вы выступаете за подход, когда изначально мы заводим шину сообщений, все операции обновления данных делаем через нее, а для синхронных запросов с фронта использовать децентрализованные заранее подготовленные представления данных.
Именно. Именно в этом случае вы реально получаете отдачу от микросервисов. И да - это сложно. Коммуникация между сервисами должна быть асинхронной.
Аргумент о зависимой разработке в микросервисах при синхронном API считаю несостоятельным - ведь вы, когда кладете сообщения в очередь для подписчиков, ровно так же их форматируете, и можете сломать там формат.
Да, поэтому там свои решения в виде схема реджистри и коррапшен лэйер и т.д. И опять же, это сложно.
И даже если структура месседжей изменилась, я просто не обновлю свои данные, а не буду возвращать пустые данные или вообще ошибку потому что сторонний сервер упал или изменил формат данных не сказав.
Тем более обидно когда на том стороннем сервисе данные меняются очень редко, а мне эти данные нужны всегда. И тут ваше возражение в виде "отдавать старые данные может быть плохой идеей" уже не катит. А любая проблема на том сервисе отразиться на моем сервисе. В конечном итоге страдают пользователи.
з.ы.
Я веду к тому, что трушные микросервисы сложны. А от нетрушных, очень профита. И даже эти профиты легко исчезают при появлении проблемы которые приходят с микро сервисами, одна из которых это нетворк.
Но я прекрасно понимаю что есть трейдофы, и иногда приходится ради фронтендеров городить backend for frontend, хоть я их и не люблю всей душой.
И если вы понимаете что это решение временное и никак не конечное (но мы то знаем что нет более постоянного решения чем временное), то ОК. Но многие новички могут начать пилить вот такие микросервисы, и потом не будут знать что с ними делать когда все сервисы будут переплетены между собой синхронными хттп запросами, и малейший баг в одном сервисе будет создавать снежный ком.
З.Ы.
У нас в легаси есть такой боттлнек, сервис аккаунты, и все остальные сервисы проверяют синхронно статус аккаунта - активный или неактивный. Если неактивный - возвращают ошибку и не дают сделать операцию.
Любая проблема на этом сервисе влияет на всю систему. Это реальная жопа. Хотя на самом деле, если подписаться на события сервиса аккаунта, и хранить информацию об аккаунтах у себя локально, в базе микро сервиса, то даже если все сломалось у сервиса аккаунтов, и мы недополучили сообщения о последних деактивированных или заного активированных аккаунтах, урон для бизнеса минимальный, потому что система работает, и пострадают только прямые пользователи сервиса аккаунт (но это бы случилось в любом случае ведь проблема именно в нем).
Нет. Вы заранее знаете где и откуда будут приходить запросы. Вы заранее подготавливаете уже агрегированные данные в удобном для запросов виде (структуре) и в удобной для соответствующих запросов базе данных.
Почитайте про DDD, CQRS.
Идея в том, чтобы реагировать на изменения в разных доменах, и каждый домен для себя строит нужные ему вьюшки с нужными данными уже внутри.
Например, вам нужно вернуть в апишке статью и данные автора. Сервис статей и сервис авторов находятся в разных доменах.
Вместо того чтобы в реалтайме ходить на 2 сервиса, вы заранее подготавливаете вьюшку где храните данные статьи и данные автора (только те данные что реально нужны, не весь объект автора который может содержать сотню полей в собственном домене).
Подписываетесь на изменения автора. Если автор изменил фамилию - ваши сабскрайберы обновляют вьюшку.
В итоге, если сервис авторов крашится, или еще чего - на уже существующий функционал это не влияет.
Сервис авторов может хромать и тормозить из-за нагрузки, но на отображение статей с данными автора это не повлияет, потому что вьюшка хранится в отдельной базе и с ней работает отдельный сервис, который скейлится по своим параметрам.
Ну это в кратце...
Потому как сейчас я не вижу преимуществ того что вы называете микросервисами.
Если кто-то из другой команды ломает свой сервис, то у меня сломается все, потому что мой апи напрямую зависит от чужого апи.
А что если у меня резкий скачок нагрузки, и мой сервис отлично авто-скейлится, но тот другой сервис не умеет или умеет но плохо? Время ответа моего апи будет зависеть от времени ответа чужого апи.
А что если мои запросы убивают тот второй сервис потому что он был не готов к таким фильтрам и сортировками? Хороше, он добавит индексы для меня, и еще +100500 клиентов, у убьет свой перформанс на write side .
Подписываясь на события другого сервиса, я могу строить у себя все что я хочу и как хочу, не мешая никому другому и не зависеть от других сервисов (до определенного уровня абстракции).
Тут конечно стоит упомянуть eventual consistency...
Ну иногда не особа есть выбор. Например когда очень жесткое требование на Exactly once delivery.
Если я не ошибаюсь, решение этой проблемы это хранить оффсеты на стороне консюмера. Что то вроде Outbox Pattern только на входящие сообщения.
Kafka Consumer starts
Load the last offset from the db
Receive message from kafka
tr = Start db transaction
handleMessage(tr)
persistOffset(tr)
tr.commit()
Или все или ничего...
Жесть конечно. Даже не представляю где человеку который этим занимается будет не скучно работать... апишки там пилить с микросервисами, с браузером бадаться =))
Сколько теории написано про DDD. А вот примеров имплементации ну хоть немного сложного агрегата с парочкой бизнес рулов, с 1-2 релейшенами, саб агрегатами и валуе обжектами я так и не нашел.
Я вот после написания ну очень простой имплементации рут агрегата с минимум полей и минимум агрегатов и value objects внутри, слабо представляю как все это будет работать при большой нагрузке, если не использовать магию ORM под капотом что бы загружать не весь агрегат и что бы сохранять не весь агрегат. И тут появлется соблазн использовать саму модель orm как агрегат что не есть хороше.
Имплементировать на каждый филд враппер прямо в агрегате что бы уметь определять как ой филд изменился а какой нет?
struct StatusField {originaldata stringnewdata stringisModified}
Особенно если апишка частично crudish...
И все ради того что бы иметь один метод reservationRepo.save(reservation);
Будет интересно посмотреть на ваше решение.
В закладки. Интересно поиграться.
Мы для эмуляции pub/sub делали эксченжи и присоединяли кьюшки что бы каждая получала копию сообщений. Работает оно, но кьюшки плодятся, мейнтенс...
Стримы интересно выглядят... надо только раббит обновить.
Но в конце концов мы в большинстве флоу переходим на кафку. Все таки partial order of messages и авто ассайн воркеров к партишинам для нас маст хэв.
Пользуем миро для евент сторминга, описания архитектурных решений и коммуникаций между сервисами, описания всяких флоу и т.д. В рилтайме можно обсудить и подправить. Удобно.
Меня смутило то что кафка стримс инстанс будет скачивать весь топик и строить таблицу в пямяти. А если у меня очень очень много данных? Например заказы с десятков или сотен магазинов. Как делается холодный старт? Что произойдет при рестарте инстансов? Или при стандартном скейл ап/даун?
Или я что-то не понял?
Ох как хочу посмотреть через пару лет на их кодовую базу без стандартных абстракций когда их же менеджеры не дадут им время на рефакторинг что бы внедрить их в будущем.
Понятно что абстрактную фабрику не нужно пихать на каждый чих, но какие претензии к репозитори/дао слою? Возврат к спагетти, который ни тестировать ни рефакторить нормально нельзя...
Выберите слоеную/хексагональную архитектуру, запилите генератор бойлерплейта, и будет вам щастье.
Сразу в любом проекте будет понятно из чего он состоит и куда смотреть в случае чего.
Я так представляю в скором времени у них что бы понять что тут в сервисе происходит нужно будет читать тысячи строк, вместо того что бы пройтись беглым взглядом по абстракциям и файликам.
Хотя сложно сказать что за абстракции у них там были что убрав их они убрали 80% кода. Сколько там строчек кода занимает интерфейс репозитори/хэндлера/сервиса?
А еще при построении кораблей нет продукт манагеров которые вдруг решают что теперь для бизнеса им нужны летающие контейнеровозы, а для очень важных клиентов чтобы еще и в космос мог залетать на пол шишечки =))
Если это b2b то есть смысл регистрацию и вход делать отдельным приложением и просто редиректить на него. Хочешь микро-фронт, хочешь вообще отдельное приложение написанное на другом стеке тупо под любым веб-сервером.
А если зарегаться может любой то смысла большого нет. Всегда можно зарегаться и увидеть все приложение.
А если у вас еще и открытое АПИ то вообще в этом все смысла нет... нужно бэк защищать и понимать что все про вас все знают. Ангуляр это или нет, вообще не имеет значение. Есть апишка - ее найдут.
Рассказали обо всем кроме самой информации об автоматизации. Как оно работает? Какие инструменты используются? Кто решает, стала ли проблема блокером или можно продолжать спать?
Смотрю на наши проблемы в продакшене, и они настолько разные, что человеку тяжело понять что вообще пострадало в результате, и что теперь делать.
Мне 35 и глядя на уровень нынешних выпускников всяких курсов и даже выходцев университетов, мне работы хватит лет до 100...
Причем владельцы стартапов стареют вместе с нами, и также понимают что опыт это очень ценный актив. Поэтому пора перестать плакать а том что карьера программиста заканчивается в 30...
Вы о CRDT?
В принципе на бэкенде тоже самое и это кстати важно понимать. Если нет трейсинга, документации/ADR, то понять бизнес будет сложно. Теряется общая картина. И вот сидишь ты и смотришь на все эти месседжи и не понимаешь а какие вообще бизнес процессы тут протекают и что с этим всем делать.
Особенный ад это когда евенты в виде крада... reservationUpdated, listingEdited. Легче застрелиться чем поддерживать такую систему.
Вы правы. Уже 4 года варюсь в message driven/event driven и система все еще продолжает удивлять. От простых ритраев которые спасают и могут и проблемы сделать если нет idempotency, до спайков которые убивают http сервисы или базу потому что воркеры скейлятся намного быстрее и нужно делать circuit breaker и рейт лимиты.
Про параллельную обработку это вообще отдельная тема...
От построения тупого POC до системы которая будет реально работать как часы, как от земли до луны.
Последний раз 3 дня копал почему у нас воркер который работает с раббитом крашится, и месседж остается все время в head и все это повторяется и вообще ничего не может процесситься.
Готовлю статью на медиуме на эту тему. Оказалось для long running CPU bound job драйвер раббита для NODEJS не может отправить heartbeat и раббит закрывает соединение =)))
P.S.
Но справедливости ради нужно сказать, все таки эта архитектура необходима если вам важны данные и важно их процессить, и важно иметь возможность управлять нагрузкой и разделать ворклоады. Если же вы готовы терять реквесты если сервис лежит, и вам не важно что один клиент может повлиять но всех остальных, то может оно вам и не надо...
Да, главное это понимать. Happy Flow везде простой, а потом начинается...
Если back compatibility не предусмотрено, то танцы с бубном обеспечены.
На сколько я знаю, мы делаем не через дебезиум, а через стандартный коннектор - https://docs.mongodb.com/kafka-connector/current/
Этим уже девопсы занимаютсяу нас.
Насчет восстановления базы - интересный вопрос. Вряд ли тут есть генерное решение. Но в принципе можно к этому относиться как частному случаю ресета оффсета опредееленного консьюмера.
Если сама синхронизация очень тупая, в виде простых идемпотентных апсертов на стороне сабскрайберов, то все должно работать out of the box.
Если же вьюшки строятся сложнее (например мерж нескольких стримов или обогащение евентов синхронно (что не очень хорошо) в консьюмере, тут уже нужно конкретно по ситуации смотреть. Возможно что-то умнее придумать при помощи idempotencyId, timestamps, маппинга оффсета на стороне сабскрайбера с данными чтобы и написание умного рикавери процесса.
Есть конечно нюансы. Например в нашем случае используются топики, где храняться несколько месседжей на определенный _id (зависит от настроек топика кафки) и нужно иметь ввиду что когда будет идти восстановление, то в какой-то промежуток времени мы можем иметь во вьюшке не самые последние данные из тех что мы имеем.
Насколько я знаю, можно настроить топик хранить только последнюю копию документа монги.
Я люблю CQRS. В нашем легаси, как один из шагов в сторону мискросервисов, DDD, евентов + трушный CQRS, мы используем CDC. В нашем случае это Mongo + Kafka connector. И сабскрайберы подписываются на изменения определенных коллекций, и уже создают у себя нуные им вьюшки, в подходящщей базе данных и в подходящей структуре.
Тьфу тьфу работает стабильно и позволяет сделать анкаплинг сервисов и получить реальный профит.
Но нужно заранее думать о том как делать рикавери если что-то пошло не так. И если все делать правильно - рикавери сводится к рисету оффсета сабскрайбера на топик.
Это не сокрытие проблемы. Это часть анкаплинга и релаябилити. Как пример, автор изменил свое имя, и мы не проапдейтили статьи, потому сервис авторов изменил структуру событий и мы не может их обработать. Юзеру пофиг. Если имя обновится через час когда баг будет пофиксен, это равносильно тому что если бы бага не было с самого начало, а сам автор решил бы изменить свое имя на 1 час позже.
Все эти случаи должны обсуждаться с домейн экспертами. В критических случаях можно показывать возраст.
Вы когда на сайте банка заходите, и вам зашла зарплата, и вы сделали какие-то покупки, вам почти всегда показывают устаревшие данные.
А теперь представьте у банка проблема и один из их сервисов упал и его будут чинить сутки. Вы предпочтете видеть 0 или устаревшие данные с надписью - "Данные актуальны на ... и могут не содержать результаты последних операций"?
Вы мыслите как программист а не как домейн эксперт. В большинстве случаем старые данные намного ценнее странички с пустыми данными.
Именно. Именно в этом случае вы реально получаете отдачу от микросервисов. И да - это сложно. Коммуникация между сервисами должна быть асинхронной.
Да, поэтому там свои решения в виде схема реджистри и коррапшен лэйер и т.д. И опять же, это сложно.
И даже если структура месседжей изменилась, я просто не обновлю свои данные, а не буду возвращать пустые данные или вообще ошибку потому что сторонний сервер упал или изменил формат данных не сказав.
Тем более обидно когда на том стороннем сервисе данные меняются очень редко, а мне эти данные нужны всегда. И тут ваше возражение в виде "отдавать старые данные может быть плохой идеей" уже не катит. А любая проблема на том сервисе отразиться на моем сервисе. В конечном итоге страдают пользователи.
з.ы.
Я веду к тому, что трушные микросервисы сложны. А от нетрушных, очень профита. И даже эти профиты легко исчезают при появлении проблемы которые приходят с микро сервисами, одна из которых это нетворк.
Но я прекрасно понимаю что есть трейдофы, и иногда приходится ради фронтендеров городить backend for frontend, хоть я их и не люблю всей душой.
И если вы понимаете что это решение временное и никак не конечное (но мы то знаем что нет более постоянного решения чем временное), то ОК. Но многие новички могут начать пилить вот такие микросервисы, и потом не будут знать что с ними делать когда все сервисы будут переплетены между собой синхронными хттп запросами, и малейший баг в одном сервисе будет создавать снежный ком.
З.Ы.
У нас в легаси есть такой боттлнек, сервис аккаунты, и все остальные сервисы проверяют синхронно статус аккаунта - активный или неактивный. Если неактивный - возвращают ошибку и не дают сделать операцию.
Любая проблема на этом сервисе влияет на всю систему. Это реальная жопа. Хотя на самом деле, если подписаться на события сервиса аккаунта, и хранить информацию об аккаунтах у себя локально, в базе микро сервиса, то даже если все сломалось у сервиса аккаунтов, и мы недополучили сообщения о последних деактивированных или заного активированных аккаунтах, урон для бизнеса минимальный, потому что система работает, и пострадают только прямые пользователи сервиса аккаунт (но это бы случилось в любом случае ведь проблема именно в нем).
Нет. Вы заранее знаете где и откуда будут приходить запросы. Вы заранее подготавливаете уже агрегированные данные в удобном для запросов виде (структуре) и в удобной для соответствующих запросов базе данных.
Почитайте про DDD, CQRS.
Идея в том, чтобы реагировать на изменения в разных доменах, и каждый домен для себя строит нужные ему вьюшки с нужными данными уже внутри.
Например, вам нужно вернуть в апишке статью и данные автора. Сервис статей и сервис авторов находятся в разных доменах.
Вместо того чтобы в реалтайме ходить на 2 сервиса, вы заранее подготавливаете вьюшку где храните данные статьи и данные автора (только те данные что реально нужны, не весь объект автора который может содержать сотню полей в собственном домене).
Подписываетесь на изменения автора. Если автор изменил фамилию - ваши сабскрайберы обновляют вьюшку.
В итоге, если сервис авторов крашится, или еще чего - на уже существующий функционал это не влияет.
Сервис авторов может хромать и тормозить из-за нагрузки, но на отображение статей с данными автора это не повлияет, потому что вьюшка хранится в отдельной базе и с ней работает отдельный сервис, который скейлится по своим параметрам.
Ну это в кратце...
Потому как сейчас я не вижу преимуществ того что вы называете микросервисами.
Если кто-то из другой команды ломает свой сервис, то у меня сломается все, потому что мой апи напрямую зависит от чужого апи.
А что если у меня резкий скачок нагрузки, и мой сервис отлично авто-скейлится, но тот другой сервис не умеет или умеет но плохо? Время ответа моего апи будет зависеть от времени ответа чужого апи.
А что если мои запросы убивают тот второй сервис потому что он был не готов к таким фильтрам и сортировками? Хороше, он добавит индексы для меня, и еще +100500 клиентов, у убьет свой перформанс на write side .
Подписываясь на события другого сервиса, я могу строить у себя все что я хочу и как хочу, не мешая никому другому и не зависеть от других сервисов (до определенного уровня абстракции).
Тут конечно стоит упомянуть eventual consistency...