Я полагаю, что преимущества выделения ваших проблем в отдельные приложения перевешивают затраты. Я бы, вероятно, начал с двух приложений (одно для основного сайта и superadmin, одно для клиентских сайтов и администраторов), имеющих доступ к одной и той же базе данных, но вы могли бы сделать 4.
Недостатком является то, что у вас нет изоляции, поскольку все ваши приложения привязаны к одной базе данных. В конечном итоге вы столкнетесь с проблемами масштабирования вашей базы данных, но если вы начнете с простой базы данных, то начнете. Одной из стратегий масштабирования позднее будет добавление подчиненной базы данных, которую используют клиентский сайт и приложения основного сайта, в то время как приложения администратора используют главную базу данных. Это вместе с ТОННОЙ массой кэширования поможет вам продвинуться далеко вперед.
Нет ничего плохого в том, что несколько рельсовых приложений имеют доступ к одной БД, однако вам понадобится способ поделиться общим кодом между вашими приложениями. Ваши модели по большей части. Я делал это раньше, бросая все свои модели в плагин, который я разделяю как подмодуль в git или как внешний в svn. Наличие отдельных приложений сделает каждое приложение меньше и проще в обслуживании.
Однако, где вы храните свои миграции? Где вы тестируете свои модели? Я бы выбрал приложение superadmin. Кроме того, вы вносите изменения в модель или схему, и теперь вам нужно проверить 2-4 приложения и убедиться, что они по-прежнему работают!
Лучшая изоляция, отдельная база данных и связь между приложениями через веб-API (SOA), и вам не нужно об этом беспокоиться. SOA Я думаю, что это путь к достижению определенного момента, но SOA может быть преждевременным, когда вы только начинаете.
Во всяком случае, наличие отдельных приложений настраивает вас на SOA, но вам не нужно прыгать выше одного дБ, чтобы начать.