Scaling a Personal Blog: Caching, Load Balancing, Read/Write Splitting, Sharding, and NewSQL

Many developers start with a basic personal‑blog backend consisting of a single cloud server running MySQL and a Node.js HTTP server, which works fine for low traffic but quickly fails under heavy load.

To handle increasing read traffic, the article recommends adding a Redis cache (a key‑value in‑memory store) to serve hot data, reducing database load, and warns about cache consistency, penetration, and avalanche issues.

When a single server can no longer handle the request volume, horizontal scaling is suggested: deploy multiple business servers behind a reverse‑proxy (Nginx) and use load‑balancing algorithms to distribute traffic, ensuring stateless server design for easy scaling.

For high availability, the article introduces Linux Virtual Server (LVS) with keepalived to provide virtual IP failover, and mentions DNS‑based load balancing as an additional layer.

Database bottlenecks are addressed through read/write separation (master‑slave replication) and sharding (splitting data across multiple master nodes). It discusses routing strategies, hash‑based and consistent‑hash approaches, and the need for middleware like MyCat to handle cross‑shard queries and maintain ACID properties.

The limitations of traditional MySQL storage (write amplification) lead to a discussion of NewSQL and LSM‑Tree based databases (RocksDB, LevelDB). TiDB, built on RocksDB with Multi‑Raft, is presented as a distributed alternative that simplifies sharding and replication.

Finally, the article summarizes the progression from single‑server architecture to a distributed system using caching, horizontal scaling, read/write separation, sharding, and NewSQL, emphasizing that these techniques together provide high throughput, consistency, and scalability for modern web services.