After following Part 1 of this series, your servers can now horizontally scale and you can already serve thousands of concurrent requests. But somewhere down the road your application gets slower and slower and finally breaks down. The reason: your database. It’s MySQL, isn’t it?
Latest now, the required changes are more radical than just adding more cloned servers and may even require some boldness. In the end, you can choose from 2 paths:
Path #1 is to stick with MySQL and keep the “beast” on running. Hire a database administrator (DBA), tell him to do master-slave replication (read from slaves, write to master) and upgrade your master server by adding RAM, RAM and RAM. In some months, your DBA will come up with words like “sharding”, “denormalization” and “SQL tuning” and will look worried about the necessary overtime during the next weeks. At that point every new action to keep your database running will be more expensive and time consuming than the action done before. You maybe better had directly chosen Path #2 while your dataset was still small and easy to migrate.
Path #2 means to denormalize right from the beginning and no more Joins in any database query. You can stay with MySQL - and use it like a NoSQL database - or you can switch to better and easier scalable NoSQL databases like MongoDB or CouchDB. The joins you need to do from now by yourself in your application code. And as sooner you do that step, as less code you have to change.
But even if successfully switched the latest and greatest NoSQL database and let your app do the dataset-joins, soon your database requests will be again slower and slower. You will need to introduce a cache.