How to Scale Your System: From Hardware Expansion to Distributed ID Strategies

Why Expand

In plain terms, no matter how much performance is optimized, there is an upper limit. For high‑traffic applications, server optimizations such as rate limiting and resource isolation help, but eventually the ceiling remains, requiring hardware upgrades like stronger CPUs and larger memory.

Expansion Strategies

Expansion can be divided into two types: whole‑machine scaling (CPU, memory, storage, etc.) and component‑level scaling (e.g., adding memory, disks, or CPUs).

Whole‑Machine Hardware

Professional server vendors (IBM, Inspur, Dell, HP) provide assembled solutions that are often more reliable and optimized than DIY builds, making them a safer choice for most users.

Components

Tech‑savvy companies may purchase individual components to reduce costs and tailor hardware to workloads: CPU‑intensive workloads need stronger CPUs, I/O‑intensive workloads need more memory, and storage‑heavy workloads need larger disks.

Typical components include:

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

Network Card : 100 Mbps → 1 Gbps → 10 Gbps

Memory : ECC verification

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

AKF Splitting Principle

The AKF principle for Redis clusters separates load across multiple machines (X‑axis expansion) while addressing data synchronization challenges. It also isolates hot business logic for Y‑axis splitting, and further distributes data geographically for additional scaling.

Issues After Splitting and Scaling

Data sharing: synchronizing data across services, requiring data centers or database clusters.

Interface calls: remote procedure calls (RPC) such as Java RMI and Dubbo.

Persistent data avalanche: database sharding, resource isolation, and Redis persistence strategies (RDB/AOF).

High concurrency: cache problems (penetration, breakdown) and data closure across multiple client platforms.

Data consistency: ensuring identical data across servers, often using distributed locks.

Database Scaling: Clustering

Distributed systems shorten task execution time, while clustering increases the number of operations per unit time. When a single database cannot meet demand, a cluster (master‑master or master‑slave) distributes read/write load across multiple servers.

Distributed ID

Large distributed systems need globally unique identifiers. Auto‑increment IDs are unsuitable due to predictability and scalability limits. Unique ID systems must meet several requirements.

Distributed ID Requirements

Global uniqueness.

Trend‑increasing order to benefit index performance.

Monotonic increase.

Security: avoid exposing sequential patterns.

Additional operational requirements include low average and 99.9th‑percentile latency, high availability (five‑nines or six‑nines), and high QPS.

Distributed ID Generation Strategies

Common strategies include UUID, Snowflake, Redis, and Zookeeper. Below are brief overviews of UUID and Snowflake.

UUID Generation

UUID (Universally Unique Identifier) consists of 32 hexadecimal digits formatted as 8‑4‑4‑4‑12. Example: 550e8400-e29b-41d4-a716-446655440000. Advantages: very high performance because it is generated locally without network overhead. Disadvantages: large size (128 bits), potential MAC address leakage, and poor suitability as primary keys in databases due to length and randomness.

Snowflake Algorithm

Snowflake divides a 64‑bit ID into multiple fields (timestamp, machine ID, sequence). The 41‑bit timestamp covers about 69 years, 10‑bit machine ID supports up to 1024 nodes (or can be split for data centers), and a 12‑bit sequence allows 4096 IDs per millisecond per node, yielding a theoretical QPS of 4.096 million.

Advantages: trend‑increasing IDs, no reliance on external databases, high performance, and flexible bit allocation. Disadvantage: strong dependence on machine clocks; clock rollback can cause duplicate IDs or service outages.

Elastic Scaling

Elastic scaling automatically adjusts resources according to scheduled peaks and releases them afterward, improving utilization. Challenges include weak elasticity of virtual machines (requiring multi‑step provisioning) and high IT costs due to over‑provisioned resources during off‑peak periods.