Scaling architectures up is often not a great challenge. I have seen several companies simply double, triple, or more their existing large architecture to solve an acute scaling need. That genre of scaling is not the goal of this book. Here we want to devise solutions to specific problems that operate as efficiently as possible.
Because our goal is to build Internet architectures that scale well, we need to look under the covers a bit. Architectures are comprised of components, and our mission is to make those components as autonomous and cost-effectively scalable as possible. By doing so, we can approach a doubling of demand as a stress on the components of the overall architecture. In most cases, these stresses are not uniform, and handling the new demand requires only scaling one or two of the architecture's internal components.
An architecture with efficient and maintainable components can scale much better than an efficient and maintainable monolithic architecture.
At the end of the day, managing large systems requires good engineering. An architect should be able to see above and beyond a set of business requirements and their corresponding engineering plans. Analysis of the business goals, an eye on the competition, surveillance of the market in which the solution plays, and a good bit of luck will result in a relatively accurate forecasting of future architectural requirements. Aside from plain, good old engineering, anticipating change is what makes a good Internet architect.
Scaling systems is a balance between cost, complexity, maintainability, and implementation latency. I honestly believe that there is no "right" proportion of each. Experience is the ultimate weapon. I am a big fan of learning from one's own mistakes. I have countless stories of stupid decisions in my early years, and although documenting them in a book would be amusing to some, it would serve little purpose. Truly learning from one's mistakes requires making them, and the ramifications of those mistakes ensure that you don't forget.