4 ms·
> if you're absolutely sure you need to be planning to run at close to Twitter or Facebook scale one day, then yep, you'd better architect from the beginning no
by cocktailpeanuts 6y ago
> if you're absolutely sure you need to be planning to run at close to Twitter or Facebook scale one day, then yep, you'd better architect from the beginning not to use joins.
If your company end up being as large as Twitter or Facebook, you probably can raise enough money to overhaul the entire infrastructure to make it efficient in your custom scenario, which is much better than prematurely optimizing when you have 100 users.
- nine_k 6y agoIndeed; the initial Twitter implementation ran on Ruby on Rails, of all things. Several hundred copies. (Remember "fail whale"?) Then they re-engineered it to scale. If they started not with a simple RoR prototype but with a ton of scalable infrastructure, they'd launch maybe a couple years later, and burn much, much more money before the launch.
- zenhack 6y ago> they'd launch maybe a couple years later If at all; probably obvious, but important to point out that in a startup environment this kind of mistake could just outright kill the company. I work on an open source project (Sandstorm[1]) that was started by a now-defunct startup. There's a repo that's unmaintained at this point (It might still work?) containing a high-scalability backend that had been used to manage Sandstorm Inc's hosted offering. Apparently they never got to the scale where they couldn't have thrown one giant server at it and been fine, and it pulled a lot of resources away from other (ultimately more important) development tasks. ...and now I'm stuck developing against mongo for no good reason :P [1]: https://sandstorm.io https://sandstorm.io