3 ms·
Responding to your edit about "a SF startup could've built out an amazing system at a fraction of the price"-- I hear that kind of attitude a lot, I'm not so su
by lemmsjid 13y ago
Responding to your edit about "a SF startup could've built out an amazing system at a fraction of the price"-- I hear that kind of attitude a lot, I'm not so sure it holds to scrutiny.
Tackling the problem of a system that must be 100% reliable, synchronous, with complete uptime from day 1 is very very difficult, and not many startup environments will prepare you for it. A lot of systems that are scaling decently now (twitter was used as an example early on) had extreme early growing pains.
In fact, I think it is impossible to build such a system without significant upfront cost, because a lot of the cost should go into the testing phase. It's almost as though you'd want to create a testing call center that receives realistic calls and needs to route them correctly, and have it running for months while the software is iterated on. A lot of effort should go into making the testing center as realistic as possible, and a lot of time should go into teasing out the inevitable bugs.
- pcl 13y agoSounds like it doesn't need to be 100% reliable, though -- they have a painful backup system in place. Also, replaying traffic from the old system into the new seems like a viable way to test out this sort of system. Or, they could have run both systems in parallel, and just sent a percentage of the traffic to the new system and slowly ramped up. I wonder why they chose to just cut over rather than doing a full and seemingly irreversible cutover. Not that many startups would have done things that way, since the nature of startups tends towards the green field. But plenty of more-established tech companies would have, I imagine.