Есть несколько веб-приложений, каждое приложение расположено на отдельном субдомене одного и того же домена второго уровня (site.com). Нужно реализовать сквозную аутентификацию пользователей: если пользователь вошел на одном из сайтов, ему не нужно входить на всех остальных (наподобие того, как это сделано у Яндекса или Гугла, например).
Было решено вынести работу с учетными записями и профилями на отдельный (центральный) сайт: если пользователь нажимает кнопку "Войти" на sub.site.com, его редиректит на site.com, после аутентификации site.com устанавливает cookie (которая доступна всем субдоменам site.com) и редиректит пользователя обратно.
Проблема в том, что в некоторых приложениях отображаются данные из профилей пользователей: например, имя пользователя рядом с его комментарием (до 1000 комментариев на странице). Поскольку пользователь редактирует свое имя на site.com, то приложение на sub.site.com ничего об этом не знает и продолжает отображать прежнее (закэшированное) имя. Я сейчас хожу и думаю, как бы реализовать синхронизацию этих данных, с архитектурной точки зрения.
Варианты, которые я пока придумал:
После редактирования профиля отправлять server-to-server запрос (например, REST или SOAP) от site.com на все субдомены.
Минусы: придется реализовать этот механизм во всех приложениях; это может снизить производительность редактирование профиля с точки зрения пользователя; проблемы, если какой-то из сайтов в этот момент офлайн.
Делать периодический server-to-server pull-запрос от всех приложений к site.com для проверки на наличие изменений и синхронизации.
Минусы: раз периодический, это означает задержку в синхронизации и соответствующие жалобы пользователей: "Я поменял имя, а в комментарии оно не обновилось".
В базах данных приложений хранить только идентификаторы пользователей, а для отображения имен рядом с комментариями делать кросс-серверный JOIN-запрос между БД приложения и БД site.com.
Минусы: ссылочная целостность, вроде как, не поддерживается (хотя это не такой большой минус, по сравнению с другими вариантами). Ну и производительность, конечно.
Хранить данные всех приложений в одной базе.
Минусы: неудобства во время разработки и деплоймента БД (инструменты для деплоймента удаляют из БД все таблицы, которых нет в проекте, так что придется все вести в одном проекте). В будущем, возможно, разные проекты будут на разных хостингах, а открывать БД в интернет или городить VPN не хочется.
Почитать про репликацию БД (MS SQL). Посмотреть, поможет ли.
Минусы: никогда не делал репликацию БД. Даже не знаю, помогает ли она в этом случае.
Разместить все веб-приложения на одном сервере и сделать какой-нибудь специальный костыль, вроде кросс-процессного shared memory (если это имеет значение, то все приложения на ASP.NET MVC, ОС Windows).
Минусы: костыль, сложности в масштабировании, проблемы с несколькими хостингами.
Есть ли какие-то еще варианты?
PS. Если ничего не понятно из того, что я написал, то вот простая аналогия: аутентификация на сайте через OAuth, например, через ВКонтакте: сайт достает имя аутентифицировавшегося пользователя и отображает его рядом с его комментариями на сайте -> через день пользователь меняет свое имя во Вконтакте, но сайт об этом ничего не знает и продолжает отображать старое имя. Отличие моей ситуации в том, что центральный сайт с профилями (ВКонтакте в этом примере) разрабатываю тоже я, поэтому могу сделать в нем все, что хочу.
