Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

Когда команда режет монолит на микросервисы, она платит за это плоскостью эксплуатации. Раньше был один процесс: одни метрики, один лог, одна ручка «перезапусти вот это». Стало девять процессов, и у каждого своя история про то, как посмотреть очередь необработанных сообщений, как остановить один маршрут, не уронив остальные, и как выкатить новую версию, не поймав окно, в котором её не крутит никто.

Обычно эту плоскость собирают заново: Prometheus, Grafana, самописный health-контроллер, скрипт деплоя, чат-бот для рестартов. Времени уходит столько же, сколько на сам распил.

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

О том, как модуль превращается в рабочий сервис с дашбордом и деплоем, была отдельная статья. Она заканчивалась тизером про кластер. Это его продолжение.

redb.Identity получил gRPC-фасад: те же маршруты ядра, тот же реестр клиентов, один токен на оба транспорта. Что внутри, как включить, что померить.

Про redb.Identity мы не раз говорили, что он транспортно-агностичен: вся логика живёт в ядре за адресами direct-vm://identity-*, а HTTP это всего лишь фасад поверх них. Звучало убедительно, но проверить это утверждение было нечем. Фасад был ровно один, и «агностичность» оставалась обещанием архитектуры, а не наблюдаемым фактом.

Теперь фасадов два. Рядом с HTTP встал gRPC: те же маршруты ядра, тот же издатель, тот же реестр клиентов, то же хранилище токенов. Один и тот же токен принимается обоими транспортами и получает от них одинаковый вердикт. Про это и статья: что именно появилось, как это включить, и почему оно особенно уместно там, где gRPC уже стал ...