What Journey to the West Teaches About Distributed System Architecture

1. Sun Wukong as an Exemplary Microservice

The famed monk and his disciples are treated as a software system, with each character representing a distinct service. Sun Wukong embodies the security‑protection service, showcasing the power and challenges of a high‑performance microservice.

2. From Monolith to Microservice Architecture

The article first defines a monolithic architecture as stuffing all functions into a single "big bucket"—illustrated by Pig Baijie handling exploration, combat, alms‑gathering, and protection simultaneously. It then contrasts this with microservices, where the team is split into dedicated services:

Sun Wukong – "monster‑fighting" (security)

Pig Baijie – "scouting" (intelligence gathering)

Sha Monk – "carrying" (data storage / logistics)

White Dragon Horse – "transport" (load balancing / transmission)

Tang Seng – "navigation" (orchestration)

Each role communicates via APIs, embodying the core idea of microservice collaboration.

3. Service Governance: The Tight‑Binding Spell

Service governance is introduced as the mechanism that manages communication, monitoring, and failure handling among services. Sun Wukong’s arrogance is likened to a difficult‑to‑manage service, and the "tight‑binding spell" is presented as a circuit‑breaker: when a service exceeds its SLA, the system automatically applies penalties proportional to the violation, aiming to restore normal operation without destroying the service.

4. Load Balancing: The Role of the White Dragon Horse

The White Dragon Horse, though seemingly just a transport, functions as a load balancer. Without it, Tang Seng can travel only 50 li per day; with the horse, the distance doubles to 100 li, a 100% efficiency gain. The horse also provides traffic tiering—ordinary routes use Pig Baijie, while rugged paths use the horse to keep the service continuously available.

5. Service Discovery: The Land‑Lord Deity

When Sun Wukong encounters unknown demons, he consults the Land‑Lord deity, which the article maps to a service registry (e.g., Nacos, Eureka). The deity supplies service information, metadata, and recent health status, enabling dynamic discovery of services.

6. Fault‑Tolerance Design: Lessons from the Three Battles with the White‑Bone Demon

The three attacks by the White‑Bone Demon represent malicious requests. The first two are blocked by firewalls, while the third succeeds, exposing two system issues: a single point of reliance on manual judgment (Tang Seng) and a lack of circuit‑breaker to stop abnormal traffic. The resulting damage mirrors a system that suffers internal conflict after an attack.

7. Distributed Transactions: The Spider and Centipede Collaboration

The cooperation between the Spider Demon (data write) and the Centipede Demon (data read) illustrates cross‑service calls. Failure in any involved service can cause data inconsistency. The proposed solution is a distributed transaction or eventual consistency mechanism, with a coordinator analogous to the bodhisattva who subdues the Centipede Demon.

8. Summary of Architectural Wisdom

The analogy demonstrates key distributed‑system principles: clear division of responsibilities, service governance via circuit‑breakers, load balancing, dynamic service discovery, fault‑tolerant design, and coordinated distributed transactions. Understanding these parallels indicates mastery of the essence of distributed architecture.