GDPR и микросервисы — внедрить функционал в каждый сервис или понаделать отдельных gdpr-only сервисов?

Question

[catanfa]

В компании есть 30 микросервисов, формирущих один продукт. По типу сообщения, сторис, регистрация, и т.д. Код частично общий, за счёт библиотек, стораджи все разные. И вот пригорело стать джидипиар комплаэнт. Для этого нужно в каждой репе сделать одинаковые по сути действия. Экспорт всех-всех данных юзера, удаление всех данных юзера, ведение лога об удалённых юзерах.

Дали эту мега таску одному бедняге. Он начал было делать, но взвыл от объёма работы, и от необходимости разбираться с каждой репой, и ругаться каждый раз с новыми ревьюерами. Поэтому он выдвигает такой план: вместо интеграции gdpr функционала в каждый микросервис он предлагает сделать брата для каждого микросервиса, c доступом в такие же стораджи, в котором будут реализованы эти самые gdpr функции и больше ничего. То есть будет у нас user-api и gdpr-user-api, chat-api и gdpr-chat-api, search-api и gdpr-search-api и так далее.

Внимание, вопрос. Какой подход архитектурно и по бест практисам верный, и почему??

Comments

[Илья]

Разделить одну таску на отдельные таски для каждого микросервиса.

Answer 1

[Иван Шумов]

Делим сервисы на 2 части: shared context и local context. Shared оставляем, local занимается только sensitive данными. Эти сервисы просто деплоятся в разные регионы, но имеют одинаковый функционал. В остальных сервисах только обезличенная информация