This is a live blog post from the SPC09 Las Vegas, speakers Simon Skaria and Umesh Unnikrishnan.
This post is about understanding the principles behind designing a SharePoint architecture and how to accommodate growth.

Topologies
Really you will need to start designing your logical architecture like consolidated vs. distributed. After that you can build it out to a physical architecture that can scale. Scaling out is for most services nothing more than adding attention servers.
On the logical side you should consider for instance isolation. Are there departments that require you to isolate certain services like search?
The regulatory restrictions may possibly also influence your topology in the sense of isolating services as may possibly be your information architecture: where to locate wikis, blogs etc.

Scaling services is about scaling within the farm as much as possible. You will first have to find out what the bottleneck is to identify the attention servers that are hosting them and add additional ones. Some services are restricted to the data layer like search. That may possibly mean that scaling SQL force be the way to go. So different service apps that connect to different SQL instances. Treatment logging data force be a very candidate for a separate SQL instance.
And finally you can scale out the Web front end tier as well.

The second deal with is to not scale within the farm but to have a separate services farm. Or even a separate make pleased farm. In a geo distributed architecture you force want to have multiple services farm for instance to host regional search services. Start really with the search because that is the most heavy one.

Sample topologies
Small company: one IIS web site for SharePoint services, one for the intranet, my sites and team sites. The my sites and team site share the attention pool. Fact that the intranet is separated on app pool level is for reliability. From a physical perspective it would mean two servers both having the web and app server role and one SQL server. How would this topology accommodate prospect growth? Adding make pleased through new site collections and by adding servers.

Medium company: typical 10-15k users, IT staff +- 10, limited intra-organizational seams and need to accommodate projects. This topology has still one farm. But they do have different proxy groups. The HR Web site may have a different metadata service for employees. So there will be another metadata service that is part of another proxy assemble. From a physical perspective they have split up WFEs from the attention servers. The app servers hosting excel, central admin, user profiles, metadata, another hosting excel, user profiles and metadata, another hosting query and another hosting index. Finally two SQL servers. Wrap up: single farm, cut off web apps, multiple service apps, multiple proxy groups, distinct server roles and they manage growth by adding sites to existing web apps and site collections, scale out by adding WFE or app servers and they force choose to further split out their make pleased farms.

Large company: this company has typically more than 50k users, geographically distributed, dedicated horizontal and vertical departments, there are organizational boundaries, often internally hosted with different SLAs.
The logical architecture in this case has multiple farms, the central services farm hosts all services that are consumed by all the individual make pleased farms like User profiles, metadata, search, Business data connectivity etc. They have separated out the My sites due to the number of users, and the intranet. The main collaboration farm has a number of sub divisions but is also hosting a number of services themselves like Infopath, the Insight services, Access services and Excel services. Between farms trusts are set up.
The physical topology is honestly complex having multiple servers sometimes hosting just one service.  So for the My Site farm has separate servers with the Treatment and health service (for instance 3 ones with only this service), index, central admin and excel, etc.
The way they accommodate growth is by adding new site collections, new web apps, new farms depending on SLA, scale out by adding WFEs and App Servers and distribute geographically through multiple service farms. The enterprise services are owned by IT.

Other scenarios: internet publishing requires a different topology. Multi-tenancy hosting.

The white paper for topologies on SharePoint 2010 has been published on TechEd.

Considerations: MOSS 2007 farms do not interoperate with SharePoint 2010 farms.

Large company:

Check it out:Serve’s Sharepoint Blog