Лучший способ разделить администраторскую функциональность от общедоступного сайта?

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

Например, сайт имеет большой социальный компонент к нему и общедоступный интерфейс продаж. Но в то же время существуют задачи бэк-офиса, объемная обработка загрузки, панели инструментов (с длительными запросами), и инструменты отношений с клиентами в администраторском разделе, что я хотел бы не быть произведенным скачками в общедоступном трафике (или произвел бы общедоступное время отклика).

Сайт работает на довольно стандартном стеке Rails/MySQL/Linux, но я думаю, что это - больше проблемы архитектуры, чем реализация один: главным образом, как каждый сохраняет данные и бизнес-логику в синхронизации между этими различными приложениями?

Некоторые стратегии, которые я оцениваю:

1) Создайте ведомую базу данных общедоступной базы данных по другой машине. Извлечение вся модель и библиотека кодирует так, чтобы это могло быть совместно использовано приложениями. Создайте новые контроллеры и представления для администраторских интерфейсов.

Я ограничил опыт с репликацией, и даже не уверено, что это, как предполагается, используется этот путь (большую часть времени, я видел его, это было для того, чтобы масштабировать горизонтально поддержку чтения того же приложения, вместо того, чтобы иметь несколько различных). Я также волнуюсь по поводу потенциала для проблем задержки, если ведомое устройство не находится в той же сети.

2) Создайте новый больше task/department-specific приложений и используйте ориентированное промежуточное программное обеспечение сообщения для интеграции их. Я считал Шаблоны Интеграции Предприятия некоторое время назад, и они, казалось, защищали это для распределенных систем. (С другой стороны, в некоторых случаях основной стиль направляющих УСПОКОИТЕЛЬНАЯ функциональность API мог бы быть достаточным.), Но, у меня есть кошмары о проблемах синхронизации данных и крупном перепроектировании, которое это повлекло бы за собой.

3) Немного смеси двух. Например, единственная общедоступная информация, необходимая для некоторых задач бэк-офиса, является временем завершения только для чтения или состоянием. Имело бы смысл иметь это в абсолютно отдельной системе и отправлять данные общественности? Между тем администраторская функциональность пользователя/группы была бы выполнена в отдельной системе, совместно использующей базу данных? Оборотная сторона, это, кажется, сохраняет многие проблемы, которые я имею с первыми двумя, особенно перепроектирование.

Я уверен, что ответы будут очень зависящими от определенных потребностей сайта, но я хотел бы услышать успех (или отказ) истории.