DeWu's High‑Availability Architecture Evolution

Large e‑commerce systems rarely start with a fully designed high‑availability architecture; they evolve as users and business grow. Providing stable services and ensuring high availability has become a core challenge for technical teams.

In this interview, core members of DeWu's technology team share their practices and evolution of high‑availability architecture, including preparation for major sales events, multi‑active regional deployment, and full‑link stress testing.

Four Evolution Stages

1. Early stage: simple business, PHP monolith, minimal HA.

2. Growth stage: migrated to Java with Spring Cloud, split domains (order, bidding, discount, merchant, product) but weak service governance.

3. 2019 “Five‑Color‑Stone” project: domain‑driven redesign, six core domains, sharding, monitoring, governance, and pre‑plan systems built in three months.

4. Current stage: active‑active, containerized deployment to achieve cross‑region disaster recovery and scalability.

Disaster‑Recovery Options

Cold standby, hot standby, active‑active/multi‑active (same‑city, cross‑city, cross‑country). DeWu adopts hot standby + active‑active, with the primary data center handling ~70% traffic and automatic failover to the secondary center.

Multi‑Region Deployment

Considerations include geographic risk, latency, and user‑centered routing. DeWu chooses near‑city active‑active to ensure real‑time data synchronization for buyer‑critical paths.

Infrastructure and Business System Refactoring

Built a dual‑active console, upgraded gateways, RPC routing, configuration, MQ, Redis, MySQL, ES, HBase, and created data‑replication and inspection services. Business systems were refactored selectively, focusing on core buyer flows (inventory, product detail, order) while leaving many B‑side services unchanged.

Platform Governance for “Natural and Man‑Made Disasters”

Prepared for hardware failures, network issues, attacks, software bugs, and human errors through redundancy, failover, replication, isolation, performance testing, rate limiting, traffic replay, and change control.

Full‑Link Stress‑Testing Platform

Implemented in 2019, the platform supports API integration via Fusion, traffic funnel modeling, mock modules, shadow middleware (MySQL, Redis, MongoDB, Kafka, RocketMQ, HBase, ES), and multi‑stage testing (single‑node, mixed‑link, full‑link). It isolates test data using shadow databases to protect production stability.

Big‑Sale (Promotion) Preparation

Divided into overall stability assurance, business delivery, and organizational support. Established SOPs for launch, planning, execution, testing, and post‑mortem. Conducted capacity assessment, risk identification, architecture governance, visibility construction, and pre‑plan rehearsals for critical buyer paths.

Key Takeaways

High‑availability architecture requires clear problem definition, mapping business challenges to technical solutions, and a systematic approach from design to operation. Architects must master microservice design, infrastructure, governance, and continuous evolution to keep systems reliable under rapid business growth.