Why Simple CRUD Apps Need Distributed Systems: From Scaling to CAP Theory

Programming is an art; its charm lies in creation. "65哥" has been doing simple CRUD work for two years and wonders why distributed systems matter.

What Is a Distributed System?

A distributed system is a collection of independent computers that appear to users as a single coherent system, communicating only through message passing. The system provides unified physical and logical resources that can be dynamically allocated.

Web Application Scaling

Initially a single server handled all requests. As traffic grew, vertical scaling—upgrading CPU, memory, bandwidth—was used. This is called

vertical scaling

, but it eventually hits bottlenecks and rising marginal costs.

Single‑machine capacity reaches a limit.

Cost of further upgrades grows rapidly.

When vertical scaling can no longer meet demand, adding more servers—

horizontal scaling

—increases concurrency.

System Partitioning

Horizontal scaling adds servers, but the challenge is making them work as a unified service. Two partitioning approaches exist:

Vertical partitioning

: split the system by modules or roles, each handling different responsibilities.

Horizontal partitioning

: deploy identical copies of the whole service on multiple nodes, each handling a portion of the request load.

Horizontal partitioning creates a

cluster

; vertical partitioning creates a

distributed

system. Both improve availability and performance.

Distributed System Goals

Transparency : users should not notice whether the system is distributed or single‑node. Includes access, location, concurrency, replication, fault, mobility, performance, and scalability transparency.

Openness : use standard protocols and interfaces.

Scalability : maintain effectiveness as resources and users increase.

Performance : outperform monolithic applications.

Reliability : provide stronger safety, consistency, and error masking than single‑node systems.

Challenges

Distributed systems face two main challenges:

Node failures: more nodes increase the chance of failure, requiring fault detection and task migration.

Unreliable networks: issues like partitioning, latency, packet loss, and out‑of‑order delivery make timeouts and uncertain outcomes common.

Divide and Conquer

By splitting computation and storage across nodes, systems achieve higher performance. Examples include sharding, partitioning, and load balancing.

Sharding

Data is divided across nodes. In MongoDB, large datasets are split into shards; in Elasticsearch, an index consists of multiple shards that are balanced across nodes.

Partition

In Kafka, a topic is composed of partitions; each partition is processed by a single consumer within a consumer group, determining the topic’s concurrency. DynamoDB also partitions tables internally.

Load Balancing

Distributes requests among servers to improve performance and reliability. Nginx, Dubbo, and Spring Cloud’s Ribbon component provide various load‑balancing strategies.

Load‑Balancing Strategies

Random: selects a server based on weight.

RoundRobin: cycles through servers, may overload slow nodes.

LeastActive: prefers servers with fewest active calls.

ConsistentHash: routes identical requests to the same server, minimizing disruption on failures.

Kafka Partition Assignors

RangeAssignor: evenly distributes partitions based on consumer count.

RoundRobinAssignor: balances partitions across all consumers.

StickyAssignor: aims for minimal changes between reassignments while keeping distribution balanced.

Replication

Replicas increase high availability and parallel read/write capacity. MySQL master‑slave setups provide read/write separation. Elasticsearch uses replica shards for failover; if a primary shard node fails, a replica promotes to primary.

CAP Theorem

The CAP theorem states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition tolerance. Trade‑offs lead to three possible designs: CA (strong consistency, no partition tolerance), CP (strong consistency with partition tolerance), and AP (availability with partition tolerance).

BASE Theory

BASE relaxes the strict CAP constraints: Basically Available, Soft State, and Eventually Consistent. It accepts temporary inconsistencies to achieve high availability and scalability, contrasting with ACID’s strong consistency.

Understanding these principles helps engineers design robust, scalable backend services that meet real‑world demands.