Полагаю, вы говорите об архитектуре программного обеспечения (в отличие от аппаратной или системной архитектуры).
Возможно, самое важное правило (я бы не назвал это шаблоном) - это разделение интересов. Это означает, что один компонент должен обрабатывать только одну задачу, только эту задачу и завершенную задачу. Если вы придерживаетесь этого (что сложнее, чем кажется). У вас будет основание для упомянутой вами возможности подключения, например, Обмен пользовательского интерфейса. Если ваш UI-слой действительно использует только UI, его можно заменить чем-то совершенно другим.
Если вы действительно говорите по-крупному, как упомянутое GMail, концепция «в конечном итоге непротиворечива» становится важной. Классические приложения структурированы таким образом, что пользователь выполняет действие, скажем, нажатием кнопки. Приложение обрабатывает это действие (например, сохраняет данные из формы в базе данных). И обновляет графический интерфейс, когда это сделано (например, замена кнопки «Сохранить» на кнопку редактирования. Преимущество этой линейной обработки заключается в том, что пользователь всегда видит согласованное состояние. Если он оборачивается и просматривает базу данных, он найдет свою данные прямо там. Но это не очень хорошо, когда у вас очень высокая нагрузка на систему, потому что оптимальная база данных для сохранения в большинстве случаев не является идеальной базой данных для поиска. Поэтому некоторые приложения делают что-то вроде этого: Когда пользователь нажимает кнопку «Сохранить», данные сохраняются максимально быстрым способом (например, база данных оптимизирована для обновлений), задается маркер для дальнейшей обработки и обновляется графический интерфейс. Теперь для обработки сохраненных данных требуется отдельный процесс. Например, путем обновления специальных индексов или сохранения их в отдельной базе данных, оптимизированной для поиска. Этот второй процесс может собирать изменения для многих действий с целью повышения производительности.
С этим дизайном вы можете масштабироваться дальше, потому что вы разделяете проблемы: хранение и поиск данных - это две разные задачи, поэтому они разделены на два разных компонента, которые в этом крайнем случае могут работать параллельно. Для пользователя это означает, что он может не сразу найти материал, который он только что сохранил, но в конце концов найдет. Следовательно, «возможная последовательность»
Редактировать: я забыл о ресурсах. Великие книги об архитектуре приложений: Мартин Фаулерс «Шаблоны архитектуры корпоративных приложений». Для шаблонов в целом, конечно: «Шаблоны проектирования» для шаблонов, связанных с архитектурой обмена сообщениями »http://www.amazon.de/s/ref=nb_ss_eb?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-alias%3Denglish-books&field-keywords=Enterprise+Integration&x=0&y=0'. Я не могу рекомендовать какие-либо книги по масштабируемости, но мне порекомендовали« Создание масштабируемых веб-сайтов ». Архитектура различных больших приложений (например, Twitter) - это тема для разговоров, презентаций и статей, поэтому вы получите много ресурсов, когда будете google> Architecture Twitter <. </p>