On Apr 5, 2011, at 11:02 AM, DavidJ wrote: > 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.
I've build apps for scale and I can say this is definitively *not* *true*. It's not just a matter of using UUID's instead of doubles or ints for your primary key and a few other tweaks. Firstly, what you need to change depends on the exact load characteristics. Often a number of levels of caching are a piece of the puzzle, but a message based asynchronous approach to mutable state in the app is often required. For example, I often use an event-sourcing style approach where any entity state in the db is simple a cache of a query of all of the events that have happened to that entity over time. it's a great approach for scaling writes effectively, but it is definitely extra effort to implement as none of the mainstream web frameworks think in terms of events and optimizing for immutability. It's somewhat easier where you're scaling for reads than writes, but there are a lot of usage specific questions that drive the best scaling strategies and IMO unless you know out of the box that you *will* have huge load, it's pure waste in the lean software development sense of the term. > Consider this scenario which I watched pay out: <snip of scaling nightmare > story> 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. And what *percentage* of the projects you've ever seen have had this issue? By definition, the number of sites that will be in the (say) top 10,000 for traffic is very small compared to the number of sites that are built. Best Wishes, Peter -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
