I know that big websites suffer from scalability issues and I guess that more servers (hardware) can help to handle scalabililty issues but I see that big websites are stuck about scalability even if they can handle the cost of new servers.

So why can big companies not handle scalability issues by more servers?

  • Because scaling hardware (up/out) does not magically scale software.
    – treecoder
    Commented Nov 8, 2011 at 16:03
  • 1
    The database is slow. 1) Add an additional Oracle DB server 2).... 3) Profit!
    – maple_shaft
    Commented Nov 8, 2011 at 16:08
  • up/out ? can you explain ?
    – AnyOne
    Commented Nov 8, 2011 at 16:11
  • 3
    It is true that scaling of websites are not trivial. But it doesn't mean companies don't do things right. I have almost never seen Google or Yahoo or Amazon not responding. It is just that many a times our last mile connection is the bottleneck. Check out white papers on Akamai's site to learn how global distribution works. Commented Nov 8, 2011 at 16:13
  • Scaling up vs Scaling out
    – treecoder
    Commented Nov 8, 2011 at 16:15

4 Answers 4


By introducing more servers, you are introducing more lines of communication and the need to keep things synchronized. This is not trivial.

The amount of communications overhead goes up quadratically with the number of nodes communicating. If you try to centralize communications you then introduce a scalability bottleneck with communications.

There are several known architectures used for scaling and none of them are simple as "add more servers".

The High Scalability Blog have featured a recent blog post just this subject.


Adding more application servers works for a while, but the effect of adding more application servers is that you increase contention on the database server.

Database servers are much harder to scale by throwing more computers at the problem. The ACID properties that underpin how databases are used do not scale across many servers. Think about simultaneously applying the results of a transaction across 10 servers, and then what happens when there are 100,000 simultaneous transactions in progress.

That is where distributed databases step in. These products do not do ACID, they do CAP. Effectively you have to choose two characteristics from consistency, availability and partition tolerance and allow the third one to slip.

The programming model is usually eventual consistency, so changes get distributed between the database servers over time. (usually in ms timescales), however this is not appropriate everywhere (e.g. Banking Sector with financial transactions).

Some systems claim to offer all three CAP properties, but I have yet to see one that truely achieves this

The distributed database does not do SQL, so the data access layer has tone rewritten. This kind of change takes time to implement, and requires new ways of thinking.

  • 3
    Also, eventual consistency isn't an acceptable situation for some industries, eg banking. This is one of the reasons why IBM is still able to sell mainframe systems despite the cost/core being much less with commodity servers. Commented Nov 8, 2011 at 18:27

"More servers" is fine - and that's what a lot of companies actually do. However, unless your software is designed to scale that way, you hit diminishing returns very fast.

Most architectures have at least one bottleneck that just can't scale by adding more servers - wether it's a database, an authentication service, network, logging... 'Throw more hardware at it' works until you move the bottleneck to that place where it doesn't work any more.

You drain a pond faster by using more pumps or more buckets, but at some point you'll have so many workers they can't all access the pool at the same time and your power company won't be able to provide enough juice to all your pumps.


Scalability is best explained as:

The ability to increase performance by adding hardware

So adding hardware doesn't "increase scalability".

Many problems are embarrassingly parallel, (like ray tracing), where many tasks can be undertaken at the same time without requiring synchronization or communication between workers, but this is not the norm.

Large websites tend to have content that is always changing and it is this property that makes systems difficult to scale. Where ever there is communication or synchronization, there is the potential for a bottleneck.

The state of a website is typically stored in a database and so this is where the main bottleneck of many websites lays. A database must remain consistent and available to be useful and this is very difficult to ensure (volumes could be written on this subject).

It boils down to, adding hardware to a problem may increase your ability to compute stuff, but planning the data flow so that adding hardware actually speeds up the job that you are performing, while at the same time having a contingency plan for hardware failure, is extremely difficult.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.