No, obviously I don't *know*. However, I've watched as businesses have gone under precisely because they didn't architect for scale at the outset. There is no reason not to it as it really is little more effort than not doing so.
Consider this scenario which I watched pay out: A site had been implemented using a standard LAMP stack (Linux, Apache, MySQL, PHP) with master-slave replication. It had been running along for a reasonable time collecting customers (around 7 months) when the exponential adoption started to hit. It was driven by a few factors, including media buzz and unhappiness with a policy change of a competing site which saw users switching over en-mass. Within about a week the number of registrations was just over 1000x what it was the week or so prior. Their reaction was to throw more web instances behind the load-balancer and spool up significantly more MySQL slave instances. Unfortunately, another week passed and the site was too slow to be usable for customers - page timeouts and just very long load-times ensued while the devs tried to retrofit the code to handle the 'eventual consistency' that results when you have many slaves replicating from a master, add a caching layer, implement application-level sharding of key tables etc. Well, there was a user backlash about the poor performance and the media picked that up also. Customer support was so overwhelmed they couldn't even reply to most help tickets. By the third week a new competitor had launched a new site that was snappy (easy when you have little traffic). However, the same customers were signing up with the new competitor in droves and however they architected their site (it was run on Amazon EC2) it withstood the test and by the end of the month there were almost no active users of the site left. After the brand had been ruined by bad press, there were few new registrations and not enough revenue to cover the costs, the owners just closed up shop and the business was history. I've seen something similar happen on two other occasions also. It is easy to say in hindsight that 'they should have done this or that', but they just couldn't react quickly enough. So, if you think you can take a system with tens of thousands of active users and loads of existing data and re-architect it for scalability and migrate a large database to a different technology within a few days, good luck to you. I don't want to even try it. Not long ago, I agree, that the best options were non-SQL stores, but that is changing. While there are not yet any inherently-scalable SQL technologies on the market, a few are getting ready to launch (and already have limited availability for pilots, beta tests etc). I'm going to stick with the minor additional effort of just architecting for scale at the outset and then if a situation like that strikes when I'm on vacation, I'll stay on vacation ;) Cheers. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
