Do you have to maintain state/session over a long period of time?
Can requests be load-balanced across different web servers or do they need to stay with the originating server?
How much content can be static?
How long can the data be cached for?
Will there be high-demand customers or topics/trends? (eg: think of how Twitter has dedicated Justin Bieber servers)
Will the traffic be bursty or climb steadily?
Is there a need for comments or user input to show up in real time? Does the content mostly come from users, or from some structured input on your end?
Does the site architecture lend itself to elastic scaling (either from your own standby machines, or EC2 style servers)?
These are just some things to think about.
Imagine you waste 2 months of scaling your website that is only getting 100 users. I've experienced this before. Tears after all.
1) Keep things as simple as possible. That means, for example, try and avoid database joins where-ever you can. Doing that would mean that in the future it's much easier to shard your databases and/or move to a different (eg, different database or NoSQL) solution.
2) Keep things stateless. State is always hard to scale.
3) Become an expert in tuning your database. Learn how to analyze queries and to create sensible indexes.
My team and I deal with high traffic portals on a daily basis (as a hosting business). I'll be happy to listen, understand, and share with you ways to scale. Feel free to get in touch.
Regards
Joe
Cache everything you can, especially expensive code sections.
Move everything that doesn't have to update immediately to cron jobs.
Whenever you can, load information on demand.
Try to think before-hand about the nature of your app, specifically, is it write heavy, read heavy or code heavy? Map out a scenario of what you need to scale first, and what isn't as important to scale, for example, would you need more app servers or db servers?
Load balance if at all possible.