Где разместить этический сервис в архитектуре решения

Что проверяют

Формулировка нарочно размытая. Интервьюер смотрит, начнёте ли вы с вопросов о требованиях или сразу нарисуете отдельный микросервис. Почти всегда следом спрашивают: что делать, если этот сервис недоступен, пропускать запрос или блокировать?

Как отвечать

Сначала уточните, что именно проверяет сервис: модерацию пользовательского контента, фильтрацию ответов ИИ-модели, запрет дискриминирующих решений в скоринге, согласия на обработку персональных данных. От этого зависит всё остальное. Дальше разберите три оси:

• блокирующая или последующая проверка: если действие нельзя выполнить без решения, проверка синхронная и стоит на пути запроса. Если достаточно отреагировать постфактум, её выносят в асинхронный поток через Kafka, и задержки она не добавляет;
• где исполняется правило: удобная схема из мира политик доступа это разделение на точку принятия решения (PDP) и точки применения (PEP). Решение принимает отдельный сервис, а в доменных сервисах стоит тонкий клиент, например HandlerInterceptor или аспект Spring;
• поведение при сбое: fail-closed (блокировать) для финансовых и юридически значимых операций, fail-open с записью в аудит для некритичных. Вызов оборачивают в таймаут и circuit breaker из Resilience4j.

API Gateway, например Spring Cloud Gateway, подходит только для простых проверок без доменного контекста: шлюз видит запрос, но не знает бизнес-смысла операции. Сложную логику туда класть не стоит.

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

Где спотыкаются

Сразу отвечают «отдельный микросервис с REST» и не уточняют, что проверяется. Без этого любое размещение выглядит угадыванием.

Не думают о сбоях. Синхронная зависимость без таймаута и запасного поведения превращает этический сервис в единую точку отказа всей системы.

Делают сервис владельцем бизнес-логики: он начинает сам менять данные и знать про все домены. Его задача выносить решение «можно или нельзя», остальное остаётся в доменных сервисах.