Architecture for social multiplayer browser game (backend choice + frontend choice [flash/silverlight])

I'm thinking about developing online multiplayer social game. The shared state of the world would require something fast on the backend, so the potential solutions seem to be:

1. fast game engine on server (eg. c++ ) and some frontend language (php/python/ruby) + flash

2. whole stack in python (using twisted or stackless python) + flash

3. .NET (asp.net or asp.net mvc) + flash

4. .NET + silverlight

first one may be an overkill from productivity point of view (3 heterogenous layers)

Nr. 4 may be programmer's heaven (common environment on all layers), but:

• No such thing has been ever built with Silverlight, maybe there are some showstoppers hiding around the corner
• It may be hard to find silverlight designers
• Despite Flash movie/clip model being criticized when compared to SL full OO architecture isn't it an advantage when it comes to designing extra parts of the virtual world by external designers? They can just prepare .swf with eg. 4 perspectives of an item on 4 frames - wouldn't it be harder with SL?
• Silvelight apparently lacks in some gaming features (like collision detection)

what do you think?

[EDIT] The game itself would be part of the bigger portal - hence it would be nice to integrate the engine with some web framework.

Option 2 -- using stackless Python -- is what Eve Online uses.

http://support.eve-online.com/Pages/KB/Article.aspx?id=128

Edit

Until you have actual software, of course, it's impossible to create an architecture that performs reasonably well. So, any judgment here is just idle speculation.

Consider the following, however.

1. Static content (.js files, .css, .png's, etc.) tend to dominate your network bandwidth. You'll have to use a reverse proxy server (e.g., squid) to handle this.

2. Squid has to get the content from somewhere. You want a lightweight file server providing static content to squid. Nginx or lighttpd or something. Apache will work for this, but -- to an extent -- it might be overkill.

3. Your dynamic content -- it appears -- will be in two forms.

   • JSON to support the game.

   • HTML to support the portal.

   For this, you'd be happiest with a mod_wsgi engine. Apache certainly does this; ngingnx and lighttpd might also work.

   • Your JSON stuff should be one set of URI's. REST is a good design pattern. Through mod_wsgi, these connect to the game-oriented server using -- if necessary -- stackless Python. Your front-end (Apache, for instance) has a location, directory or virtualhost to filter these URI's and route them to a mod_wsgi daemon that serves the game. Look at Wekzeug to build this.

   • Your HTML stuff is another set of URI's. Through mod_wsgi, these connect to a Django server running conventional Python. Your front-end (Apache, for instance) has a location, directory or virtualhost to filter these URI's and route them to a mod_wsgi daemon.