How not to launch a web 2.0 product, or, scalability in the modern internet
With the failed launch of Google Analytics and its inability to deliver immediate statistics and tracking uniformly across the blogosphere, I thought I’d bring out a few big no-nos we can all learn from.
First, don’t touch paying customers. If you roll out a free system and a pay system with identical functionality, the service agreements must be different. Free customers have no expectation to 100% reliability, so create a special network just for them. You can redirect them when they login, for example.
Second, don’t deliver a batchy service. You should be able to handle realtime traffic and analysis. Even if your backend is batchy, it should update with a high level of regularity. Real time data demands a real time system.
Third, support an infinite number of users. There’s nothing worse than closing off signup because you’re overwhelmed, or seeing a “too many connections” error message. There should be no restriction on the number of users that can register for an use your new web service, because you built it to scale. Just add more machines, right?
Fourth, support bursty traffic. You know when you launch something very cool, especially if you’re a big company (Google, Microsoft) that you will need to deal with a huge surge of interest at launch. So you should probably have a special pool of company-wide product launch machines that you can utilize until the spike is over.
Fifth, be reliable. By this I mean that if you provide any kind of data-gathering service, it cannot go down. If you’re tracking my advertising dollars, my website statistics, or some other fact, you must continue gathering and recording that data unless the earth ends. You can fail to analyse or process it and queue it up for the future if absolutely needed, but you may not destroy my data.
Sixth, make it easy. Your software should be able to partition the problem into parts that can solved by many machines in parallel. Your software should allow you to task new machines instantly and get them up and running with the rest of the cluster with no hassle. Your software should detect and correct for machines that go down automatically. Your software should detect and repurpose new machines to do their work. Your software should leverage the end-user as much as possible to save load on your servers.
If companies paid more attention to scaling considerations, they wouldn’t suffer such embarrassing product launches. There’s no point in hype if when we all look at you, there’s nothing there.
This entry was posted on Tuesday, November 15th, 2005 at 6:25 pm and is tagged with real time system, real time data, support bursty, product launch, google, free customers, t touch, website statistics, service agreements, blogosphere, infinite number, regularity, scalability, analytics, web service, expectation, partition, error message, spike, restriction. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback.
on November 15th, 2005 at 7:08 pm
More on analytics
Elliott Back has a great post on how not to ” launch a web 2.0 product, or, scalability in the modern internet”. His points:
Don’t touch paying customers
Don’t deliver batchy service
Support an infinite number of users
Supp…
on November 15th, 2005 at 10:33 pm
you forgot…
Seven - Get lots and lots of peanuts for the critics in the gallery
on November 16th, 2005 at 2:48 am
Web 2.0-Projekte
Wo wir gerade bei Google sind: Analytics funktioniert immer noch nicht richtig, wohl auch nicht für Kunden, die die 199$ im Monat für Urchin bezahlt haben und jetzt natürlich richtig stinkig sind. Die Lehren, die Elliott Back daraus zieht, sollte…
on November 16th, 2005 at 11:03 pm
Per the “reliable” and the fact that this is a data-collecting service, there ought to be more than one server in case one should go down - nothing’s invincible. Moreover, it should be somewhere free of natural disasters. Servers based in New Orleans? Bad. Servers based in the Keys? Idiots. ;P