$$$$$$ income on $$$ costs
$$$ income on $ costsRunning anything on a single server, however, is really a non starter for anything remotely serious. What do you do if you need to do an OS update? I suppose you could just never do those, like a former employer (1000+ day uptimes...)
You'd definitely need at least two servers. But I think you could surely just have simple master/slave replication and switch between them.
Source: https://foreignpolicy.com/2009/06/16/state-department-interv...
You absolutely would not. The cost of having developers put out extremely optimized code (due to the scaling limits) and cuddle that single server to never, ever fail easily eclipses the cost of a having a multiple servers by a few orders of magnitude.
EDIT: To the downvoters, I'd really love to see the calculation on how engineering time would be cheaper than buying a second server in any reasonable timeframe.
(You are right, servers are cheap compared to employee costs though.)
With a second OS partition, the server can alternate between the working copy and a copy that is updated in a VM. For a free service, customers cannot complain even if there is a reboot every day and the service is down for a couple of minutes.
Realistically, there would be a mirroring server to be prepared for hardware failures. One server can be restarted while the other is the main server.
Are you seriously suggesting that a service (the size of Twitter, no less) has an acceptable downtime of a few minutes a day?
> Realistically, there would be a mirroring server to be prepared for hardware failures. One server can be restarted while the other is the main server.
But for that mirroring, you need to replicate disk writes, databases, backups etc.. This additional load would easily bring the server to a point where a single server would no longer suffice, even an insanely spec'ed one.
Everyone has to be employed so it's better to keep adding more crap to products and make those products disposable in order to give people a job.