Позволю себе докинуть сюда в разной степени платные https://www.visual-paradigm.com/ и https://sparxsystems.com/products/ea/index.html

В обсуждаемых кейсах не идёт речь про горизонтальное масштабирование. Тут волнует, чтобы каждая конкретная задача гарантированно вычислялась не дольше 0.1 мс вместо 10 мс, условно

Обычно после небольших раскопок выясняется, что речь не об 1 задаче за 0.1, а о 100 задачах за 10.

Пользователь визуально latency < 50 мс не замечает.

Ну не всё ж веб

*место_веба_в_ИТ.jpg* :)

может, людям нужно сигналы от датчиков реактора обсчитывать, укладываясь в тик таймера

Я такие жёсткие требования видел только в прогинге микроконтроллеров, но там RTOS, жёсткофункциональная прошивка, и по сути микроконтроллер сам оказывается микросервисом.

Это бизнес-требования, или это система диагностики положения закрылок Боинга?

Ну, еще бывает FHT, но там свои собственные решения обычно.

звонки в телекоме ещё, например.
Там, конечно, не 0.1, но на всё установление вызова таймер 4-8 секунд, за это время должны отработать минимум два коммутатора, несколько маршрутизаторов, чарджинг и пачка допсервисов, причём почти всё последовательно.
В итоге на каждый элемент у тебя остаётся сотни мс дай бог

HFT да. DPI какой-нибудь. Банковский процессинг.

Возможно, мы по-разному гранулируем микросервисы. Я их гранулирую по предметным областям, и по предметным областям это сильно похоже на 1 задачу. Не надо её делить.

В банковском процессинге как раз требований по времени не очень много. Несколько секунд - вполне нормально.

А ещё я за statefull, поэтому таблица маршрутизации в момент обращения к микросервису должна быть в оперативке, а не в Redis каком-нибудь.

Это пока до HFT не дохожит. Там действительно требование отклика жёсткое. Но там опять же роутер по инструментам и matching engine на инструмент, так что намотать какой-то серьёзный latency не получится.

Э, а что хорошего в statefull?
Хотя таблица маршрутизации - да, лучше бы в оперативке, кто бы спорил.

stateless-микросервисы по мне так это полубеременность. Для stateless есть serverless-архитектура с её лямдами. Но реально это перекладывание нагрузки с сервиса на БД, будь то Redis, Mongo, MSSQL. Не важно, всё равно у процесса стейт есть, и его надо где-то держать. Моя позиция, что выталкивание стейта в Redis не даёт права называть архитектуру stateless. Ну а прелесть сервиса (микро, милли, нано, гига, любого) как раз в том, что он позволяет содержать кэш в оперативке и работать этому кэшу со скоростью оперативки. Конечность этого кэша и позволяет долго жить на одних и тех же ресурсах, не прибегая к горизонтальному масштабированию.

У вас тут уже горизонтальное масштабирование есличо.

Вот представьте, что мы сейчас делаем тот самый роутер

Наверно, потому что один matching engine начал проваливаться, и вы решили прибегнуть к горизонтальному масштабированию?