Why Scale and How: Hardware Expansion, AKF Splitting Principle, Distributed ID Generation, and Elastic Scaling

Why Scale

In plain terms, no matter how much you optimise performance, there is an upper bound; for high‑traffic applications you must optimise servers (rate‑limiting, resource isolation) but eventually you need to upgrade hardware—stronger CPUs, larger memory, more service windows—just like adding more counters in a cafeteria when the crowd grows.

Scaling Strategies

Scaling can be done either by expanding an entire machine (CPU, memory, storage) or by expanding individual components such as memory, disk, or CPU.

Whole‑Machine Hardware

Professional server vendors (IBM, Inspur, Dell, HP) provide pre‑assembled, well‑balanced hardware that is generally more reliable for most users than DIY assembly, because they have experience in component pairing and optimisation.

Component‑Level Expansion

Tech‑savvy companies may purchase raw components and assemble servers themselves to reduce costs and tailor hardware to workload characteristics—CPU‑intensive workloads get stronger CPUs, IO‑intensive workloads get more memory, storage‑heavy workloads get larger disks.

Typical components include:

CPU : Intel, AMD – frequency, core count, etc.

Network Card : 100 Mbps → 1 Gbps → 10 Gbps

Memory : ECC‑protected modules

Disk : SCSI HDD, HHD, SATA SSD, PCI‑e SSD, NVMe SSD

AKF Splitting Principle

The AKF principle for Redis clusters separates scaling into X‑axis (horizontal machine expansion) and Y‑axis (business‑level hotspot isolation). X‑axis spreads requests across many machines, while Y‑axis isolates hot business logic for targeted scaling.

After business splitting, if a hotspot still exceeds capacity, the data can be replicated across multiple data‑centers (e.g., Hubei, Beijing, Shanghai) to serve users from the nearest location.

Problems After Splitting and Scaling

As systems grow, they are broken into independent yet interconnected services (trading, finance, logistics, etc.), which introduces challenges such as data sharing, RPC interface calls, data persistence avalanches, high‑concurrency issues, and consistency guarantees.

Data sharing – how to synchronise data across services; solutions include data centres and database clusters.

Interface calls – remote protocols like RPC, Java RMI, Dubbo.

Persistence avalanche – sharding, resource isolation, Redis RDB/AOF strategies.

High concurrency – cache‑related problems (breakdown, penetration, avalanche) and data‑loop consistency across multiple client platforms.

Data consistency – often solved with distributed locks.

Database Scaling: Clustering

Distributed systems focus on reducing task execution time, while clustering increases the number of operations per unit time. When a single database cannot meet demand, clustering (master‑master or master‑slave) distributes reads and writes across multiple servers.

Distributed ID

Large‑scale systems need globally unique identifiers. Auto‑increment IDs are predictable and unsuitable for sharding, so solutions like UUID, Snowflake, Redis, or Zookeeper are used.

Distributed ID Requirements

Global uniqueness.

Trend‑increasing (ordered) for efficient indexing.

Monotonic increase.

Security – avoid exposing sequential patterns.

Additional operational requirements include low latency, five‑nine availability, and high QPS.

UUID Generation

UUIDs are 128‑bit identifiers represented as 36‑character strings, e.g., 550e8400-e29b-41d4-a716-446655440000. They are generated locally with high performance but are long, storage‑inefficient, and can expose MAC addresses.

Snowflake Algorithm

Snowflake splits a 64‑bit number into timestamp, machine ID, and sequence fields, allowing up to 69 years of timestamps, 1024 machines, and 409.6 M IDs per second. It yields trend‑increasing IDs without external dependencies, but relies on accurate system clocks.

Elastic Scaling

Elastic scaling automatically expands resources according to a schedule and releases them later, smoothing predictable load spikes. Challenges include weak elasticity of virtual machines (slow provisioning) and high IT costs due to over‑provisioning.

Automating “one‑click rapid scaling” can greatly improve elasticity, reduce manual errors, and lower costs.