Of course. Give the numbers a randomly generated id, and check for the winning value server side. You'd also want display the numbers in a way where it's tougher to compare them than checking the text values--the target value is $('#left h1').text().trim(). So that means using images (not named 1.jpg!) or canvas or something like that.
Also, your app is vulnerable to replay. I can keep POSTing the same request over and over and my score increases.
Most web sites can grow significantly without having to do data partitioning. Simple replication should be considered as a first option, especially if your read/write ratio is high. Also, you don't have to implement a lot of extra logic in your application; just write to your master and read from the slaves.
1. Can't give you any real numbers, but dude, it's Oprah.
3. Any cdn should be ok. You just want to offload those files to somebody else. Remember that browsers will only download a few resources from a single domain concurrently, so even if you have a subdomain for statics you'll get a faster page load. Hint: use yslow for more frontend optimization tips.
6. Authorize.net can handle it--we used them. But if your shopping cart can't, it's always nice to have a Paypal 'buy it now' button ready to go. Not real elegant, but it's a backup plan.
First off, congrats! I was in charge of the website when Oprah featured The Secret a few times on her show. Here's a few pointers from my experience.
1. Remember the show airs in Chicago in the morning, then more than once across time zones, so this will be an all day treat. We had a lot of buzz (Oprah's own forums went down under load for our show), and our URL was displayed on the screen. Regardless, you can expect a lot of traffic, mostly during the show and a few days afterward.
2. Your db will likely be your bottleneck. Make sure you don't have any unoptimized queries, or better yet, cache as much as you can so you're only hitting the db on writes for all the orders you'll be getting.
3. If possible, offload static content to a cdn. Akamai saved us here, because the site was not optimized size-wise.
4. What ultimately caused us issues was slow clients. I would definitely try to have a caching proxy up front. The snowball effect would cause us to tap out our 100Mb connection at times. Since you're using cloud hosting hopefully that's not a hard limitation for you.
5. It's really fun watching your bandwidth. I used a console tool called bmon. You'll be able to tell when commercials happen during the show.
6. +1 for a backup plan. Have a static page ready that you can switch over to. I'd highly suggest having an alternate payment processor, even if you have to go with Paypal. Since you're SAAS, you can't rely on retail or Amazon, so you may not get visitors to come back if your site fails. Make sure you can capture those customers the first time.
7. If you don't plan on having a free account, offer something so you can build your customer list and capture contact info. A whitepaper, newsletter, etc.
The first answer that comes to mind is tooling. At one extreme you have SOAP, where your IDE can make complete proxy objects from a WSDL file. At the other end is REST, where normally you're in luck if there's a nice client library to translate request/response into objects, but otherwise you're left with API documentation. (Is anyone really using WADL?) Somewhere in between is XML-RPC, where you're more than likely to find some kind of reflection method to call such as client.get_methods or something similar.
I think it's inexcusable to cancel a contest, even if you only get a single entry. API providers can require registration to the contest, then monitor the usage metrics based on API keys. This would give an indication of how much development is happening before the contest deadline. If it's not much, extend the deadline, but don't cancel it. As far as quality of the submissions, it's not reasonable to expect polished, production quality work. The goal should be creative or novel prototypes that demonstrate a use case of the API. To me, a good entry would be one that clearly shows how the API is being utilized. Finally, if you've got good prizes(check),
an iteresting API to play with(check), and a site to support the API(check), and you can't attract developers, you're doing something very wrong or not trying very hard.