Sharding you analyze the users pulling the biggest load off your database and separate them into shards so rather than User A hitting the main server, they hit a shard of that data server, same goes with User B; in essence you separate the people requesting the most out to individual boxes rather than the main one. Employ an army of cheap Linux boxes to create this modified farm and balance the data requests strategically out so they're evenly hit.
It's a federated model, groups of users are stored together in boxes of shards.
So if one box goes down, the others still operate. The work is shared out among your virtual server farm, you get more write performance and you reduce the bottleneck, but you also work out where you're main draw is an share that out so one guy isn't left doing all the work.
There are some disadvantages in going this way but it's a good start in solving a potential problem as your site grows.
You can also employ Linux's Native Kernel Load Balancer to help (Google this), plus there are two packages available for the O/S to help in this area:
Clustering may also be a good thing to look at, which is like sharding but simpler in that you build a farm of servers and load balance the users across them. So the first user hits box 1, then the next user hits box 2, and so on; once each box has a user you go back to box 1 and add a user, and so on balancing the load out.
Content Delivery Network's are widely available. The process takes your content and seeds it onto seperate servers across the world, so if someone requests something they receive it from the closest source near their location.