Немного о будущих цифрах:
Организаций: ~ 2000
тренеров: ~ 15000
спортсменов: ~ 25000
Заявок: ~ 100000 в год
С нагрузками проблем не будет, не беспокойтесь.
Возможно следует сделать один сервис Мероприятия, который будет объединять в себе всё это?
Да. Микросервисы про независимую разработку разными командами и независимый деплой.
Для разработки приложения в одиночку они не нужны совсем. Это огромное усложнение впустую.
Тогда как организовать лучше слабую связанность в сервисе, чтобы можно было менять одну регистрацию на другую?
Внутри монолита приложение так же прекрасно разбивается на модули/контексты, как и в микросервисах.
Например, сделали новую регистрацию v2.0 и теперь нужно заменить. Или дописали новую - нужно добавить. Интерфейсы?
Да, интерфейсы, IoC, контроль зависимостей, декомпозиция, итеративное проектирование и рефакторинг.
Имеет ли смысл регистрацию и счёты разделить на свои отдельные сервисы.
Имеет смысл ложить вместе те данные, которые вместе меняются и используются. Постарайтесь ответить для себя на этот вопрос. Так же помните что лучший выбор решения - не выбирать а отложить на потом.
3. Имеет ли смысл делать общий сервис Person? Или в каждом сервисе добавить Member, Teacher, Artist Organizator?
Сквозной функционал между сервисами это плохо т.к. плодит зависимости и влечёт каскадные изменения после каждой правки. Делаете сервисы так чтобы им не было важно, Teacher там, Member или Artist.
От монолита точно стоит уходить.
Нет.
p.s. Хотите использовать что-то крутое и сделать ваш проект лучше и качественнее - пишите unit-тесты.