Ну вот sendgrid в моем примере это микросервис? согласно твоей

логике

Нет, это внешний сервис, который ты юзаешь по API. Как у них там устроено - неизвестно

а если бы твоя компания (ну вот давай повоображаем) купила сэндгрид как компанию и теперь это внутренний продукт

а в случае микросервисов важно "как там устроено"? у тебя ж всеравно весь сервис рассылок деплоится как одна штука. у тебя вот тоже "сервис который юзается по API и для тех кто сервис юзает хз как оно там устроено"

Тут, понимаешь ли, грань между монолитом и микросервисом довольно тонкая, как ни странно. В одной из книг по мс (название я не помню), было сказано "микросервис - это проект, который по размеру такой, что его может разрабатывать команда из такого количества людей, которое можно накормить одной пиццей". Т.е. это, как я понимаю, около 3 человек. Как ты понимаешь, это может быть довольно большой проект, если исходить из такого определения

Не, там ещё стата вынесена, она отдельно деплоится

я пытаюсь подтолкнуть тебя к мысли что нет грани между "монолитом и микросервиСОМ" потому что отедльный микросервис это просто маленький монолит

Ну по сути да, дробить-то можно до посинения)

и смысл именно в не в "отдельный микросервисах" а в том как ты разделил отдельно взятый продукт на сервисы. Не имейл рассылки а то что прмя бизнес логика. То где нужны эксперементы и быстрая выкладка. а то что ты приводишь это оптимизация инфраструктуры

Кстати, многие так и делают зачем-то. При этом ни в одной книге по мс не говорилось, что "ты должен дробить, пока дробится"))

у Нюмана есть отдельная глава посвещенная "размеру сервиса" - размер меряется когнетивной нагрузкой который дает функционал.

Ну да, поэтому мы это всё просто сервисами называем, а не микросервисами