First of all you need to ask yourself, what do you need to scale? Number of authors? Amount of Content? Requests served? DIfferent questions, different ways of doing it.
There are many ways to scale Magnolia - one thing is the built-in subscriber mechanism, so its straightforward to have lets say a HW load balancer and two (or more) public facing machines to handle the requests. You can write a custom Apache (or other) cache module (has been done before) or write a custom cache handler (cache is pluggable in Magnolia) if what exists with respect to caching is not meeting your requirements. You can cluster the repository (with the upcoming Magnolia & Jackrabbit 1.2).
You can use Akamai for caching (has been done for France24.com, a massive global news website). This site, powered by Magnolia, has content in English, French and Arabic, movies, audio, text, images, is updated simultaneously with the TV channels and has handled 50000 (fifty thousand) simultaneous requests when launched.
Last week we launched lastminute.com.au, the leading travel site in Australia, with booking integration, white-labeling of content, partial content delivery and other extravaganza. Their requirements are also pretty high regarding performance and scalability (they expect to grow).
(For partial content try this:
In addition, we do have a portlet bridge in the EE that runs nicely with Liferay, in fact we currently do a joint project for a car manufacturer. It works very well, and scales the same way it would with standalone Magnolia, since the same mechanisms are used (each Liferay instance contains a Magnolia subscriber that handles the content).
Magnolia is now in its forth year of development, its pretty mature and we have a lot of experience with what works, how, when and why - or not. If you have questions, feel free to download our Magnolia Enterprise Edition and make use of our free evaluation services to help you get the most out of your time spent on evaluation. (Details come with the download).