Я предлагаю такую архитектуру.
Я бы делал так.
По-моему архитектура этого проекта очевидна.
Все очень просто.
Элементарно, Ватсон.
-----
Процесс поиска ошибки в рабочем коде называется отладка. 
Большинство кода требуют отладки!
Для начала перезагрузим консоль.
Сразу абстрагируемся от MVC парадигмы.
RestFull напишем на Java.
Web-морду напишем на РНР.
Напишем несколько сервисных функций: там регистрация, авторизация, движок для HTML, пр.
Все запросы будут отправляться с помощью JS.
Фронтэнд конечно же на HTML5 + CSS3.
Еще же нужна статистика – кинем ее на RestFull Java.
Возьмем для этого отдельный RestFull.
Если для конкретной платформы – С++.
Можно конечно C++ Qt но это если очень хочется.
Нужно взять какой нибудь легкий JavaScript-фреймворк.
Нужно обязательно продумать структуру приложения.
Возьмем какой нибудь графический тулкит.
Сделаем удобную обертку над API.
Это как синхронный цикл в Meteor.
Запишем в лог информацию о недошедших или битых tcp пакетах.
Закодим watchdog для docker.
Выделим отдельный дроплет для каждого микро-сервиса.
Повесим observer на каждый инстанс.
Ядро системы оформим в виде binary-пакета с true-crypt шифрованием.
Возьмем Apache-совместимую файловую структуру проекта.
Необходимо будет автоматически скейлить облачные серверы.
Проработаем наилучшую архитектуру для back-end коннектора к различным API.
Разделим архитектуру SaaS-приложения на авторизированные/анонимные пакеты.
Побьем весь проект на бандлы.
Напишем врапперы для доступа к сырым данным.
Не стоит забывать о системе администрирования демонов.
Следует заранее спроектировать все Content Provider-ы.
Постараемся по возможности поддерживать мультиагентную архитектуру.
Сразу же стоит определиться с архитектурой клиент-серверного взаимодействия.
Ну и админу надо десктоп приличный.
Первым делом нужно подготовить консолидированные данные для сервис-ориентированной архитектуры.
DDD, Layers, Persistence Ignorance.
Нужен будет демон для инвалидации кеша.
Сразу внедрим типизированные Request и Response.
Нужно будет только определиться с Entity Interface.
Спроектируем на бумаге архитектуру классов модели.
Аутентификация REST API только по SSL.
Настроим gzip-сжатие на бекэнде при передаче первоначальных данных сайта фронтэнду.
Все получится благодаря N-Layer архитектуре.
Вынесем в отдельный слой DataMapper, Identity Map и все связанные объекты.
Архитектуру проекта построим на WCF-сервисе.
Прототип можно за пару часов набросать на Silex или Lumen.
Обязательно нужно написать модульные, функциональные и приемочные тесты.
Не плохо было бы сразу определиться с версионированием БД.
Необходимо еще на этапе проектирования заложить возможность интеграциии с облачными сервис-провайдерами.
CDN поднимается за 10 минут.
Первым делом создадим абстрактный класс для фасадов.
По минимуму синглтонов.
Обернем final-классы декораторами.
Напишем тулзу для поддержки актуальности UML-диаграмм.
Перепишем foreach'и на while.
Сразу заложим возможность обрезать формат страниц.
Когда проект разрастется запилим свой QueryBuilder.
Компилить будем на своем форке g++.
В этом проекте самое место для Declarative Transaction Management.
-----
А вообще все это можно сделать на одних callback'ах.
И что бы ни одного onclick'a в HTML!
Только не понятно где здесь C++?
Главное не забыть о бекапах.
Пацаны такое вообще на WordPress'e делают.
В общем в энтерпрайзе делают так.
Ну а если сильно не заморачиваться то это все можно на процедурке написать.
По-моему я где-то видел плагин для jQuery, решающий подобную задачу.