I guess you are talking about software architecture (in contrast to hardware or system architecture).
Possibly the most important rule (I wouldn't call it pattern) is seperation of concerns. Meaning one component should handle exactly one task, only that task and the complete task. If you stick to that (which is harder than it seems). You'll have the basis for the plugability you mentioned, e.g. exchanging the UI. If your UI layer really does only UI, it can be replaced by something completely different.
If you are really talking big, like the mentioned GMail the concept of 'eventually consistent' becomes important. Classical applications are structured in a way that the user performs an action, say pressing a button. The application processes that action (e.g. saving data from a form in a database). And refreshes the GUI when it is done (e.g. replacing the 'save' button with an edit button. This linear processing has the benefit, that the user always sees a consistent state. If he turns around and searches the database he'll find his data right there. But this doesn't scale to well, when you have extremely high load on the system, because the optimum database for saving, is most of the time not the perfect database for searching. So some application do something like this: When the user hits the save button, the store the data in the fastes way possible (e.g. a database optimised for updates), set a marker that further processing is needed and refresh the gui. Now a separate process comes along to process the saved data, e.g. by updating special indexes or by storing it in a separate database that is optimized for searching. This second process might gather changes for many actions in order to improve performance.
With this design you can scale further, because you are separating concerns: storing and searching data are two different tasks, so they are split in two different component, which can in this extrem case work in parallel. For the user this means he might not immediately find the stuff he just saved, but he eventually will. Hence 'eventual consistency'
Edit: I forgot about the resources. Great books about application architecture are: Martin Fowlers 'Patterns of Enterprise Application Architecture'. For Patterns in general of course: 'Design Patterns' for Patterns concerning Messaging Architecture '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'. I can't recommend any books on scalability, but 'Building Scalable Web Sites' was recommended to me. The architecture of various big applications (e.g. Twitter) is a topic of talks, presentations and papers, so you'll get lots of resources when you google > architecture twitter <.