3 ms·

Thing is if you want to scale to FB size you _have_ to re architecture / redesign. No one starts an application with the farm model and multiple colos.

• geezerjay 7y ago
  You've missed the point. The argument is that eventhough aiming for FB scale is absurd, some considerations should be taken under consideration from the start. We're seeing YAGNI-style arguments being abused to sell the idea that just because it's absurd to think 10 steps ahead it's also absurd to think 2 or 3 steps ahead, which makes no sense at all.
• toast0 7y ago
  Starting with two colos might be a good idea -- at least at the point where you start thinking of adding a second machine for data availability, it may as well be in another colo so you have a disaster recovery option. Starting with partitioned data is a lot bigger jump. At most, I would say avoid building features that would require heroic efforts to implement in a partitioned world, but a single database can get huge these days, and maybe even huger by the time you need to scale. Chances are, 2TB of ram and 64 cores will fit your live DB needs; and if not, you'll know with time to make something else work
  • geggam 7y ago
    Start with a hosted DB service in the cloud. When you outgrow that then start thinking how to scale. 1st start sharding the data, then think about splitting a few services out if they are changing faster. This concept we need to go full microservices multi region right from the get go is silly and wasted time / effort. Until your idea sells and your market grows there is no reason to concern yourself with the logistics of scale.
• empath75 7y ago
  Sure and that’s fine, but you don’t want to have to do it when you go from one server to two servers, you know? Plan at least a little bit ahead.