Mastering Scalability: From Simple MySQL to Cloud‑Native Sharding Architectures

Scalability

Scalability of architecture is closely related to concurrency; without growth in concurrency, high scalability is unnecessary. Two common scaling methods are:

Scale‑up (vertical): replace machines with more powerful ones.

Scale‑out (horizontal): add nodes to increase capacity.

For high‑concurrency internet applications, horizontal scaling is the viable path; vertical scaling alone is not a long‑term solution.

Ideal State of Scalability

A service should handle higher concurrency simply by adding machines without any downtime.

Evolution of Architecture

V1.0 Simple Site Architecture

A small site can use a single MySQL instance for all reads and writes (ignoring backup). All data resides in one database.

Data storage bottlenecks at this stage are:

Total data size exceeds a single machine’s capacity.

Indexes (B+ Tree) cannot fit in memory.

Read/write mixed traffic exceeds instance limits.

Only when one of these constraints is reached should the architecture evolve.

V2.0 Vertical Partitioning

When V1.0 hits limits, the simplest remedy is vertical partitioning: split loosely related data into separate instances, optionally adding a cache layer for read‑heavy workloads.

However, the same bottlenecks as V1.0 remain for each instance.

V3.0 Master‑Slave Architecture

To solve read pressure, a master‑slave setup replicates data in real time; the master handles writes, slaves serve reads, suitable for write‑light, read‑heavy applications.

The main bottleneck becomes write capacity on the master.

V4.0 Horizontal Sharding

When vertical or master‑slave solutions hit limits, horizontal sharding distributes data across multiple clusters, each holding only a fraction (1/n) of the total dataset.

Routing is based on a sharding key. Common strategies:

Range: split by continuous key intervals (e.g., UserId ranges).

List: assign non‑continuous keys to specific clusters.

Hash: hash the key (e.g., UserId % n) to determine the cluster.

Horizontal sharding introduces challenges: all operations must know the sharding key, and auxiliary indexes (e.g., username → userid in Redis) are needed for queries on non‑key attributes, raising consistency concerns.

V5.0 Cloud‑Native Database (SaaS)

In a SaaS context, scalability must be transparent to the front‑end and fully automated. Introducing a proxy that parses SQL, determines the target cluster by sharding key, and routes reads/writes to master or slave achieves this.

The proxy also handles automatic scaling: adding a “sync slave” to replicate data, splitting clusters, and performing hot‑switches without service interruption.

MySQL Fabric and similar tools are potential solutions for automated sharding and scaling.