Designing a Disaster Recovery and Data Backup System for JD 秒送 LBS C‑End SOA Services

The JD 秒送 front‑end is a critical traffic entry point, and its stability and disaster‑recovery mechanisms are essential. This article examines how to build an LBS C‑end SOA service disaster‑recovery system, covering data backup strategies, differences between B2C and O2O scenarios, cost‑effective storage for billions of POI records, and the trade‑off between cost, solution, and user experience.

In SOA systems, disaster‑recovery capability is vital for stability. Multi‑data‑center deployment, automated failover, and data replication (master‑slave, active‑active) improve resilience. Regular DR drills and stress testing are also key to maintaining high availability.

With JD 秒送’s rapid traffic growth, LBS‑based user transactions require distinguishing strong‑real‑time and weak‑real‑time data to define appropriate backup strategies. The massive POI dataset (hundreds of millions at 75 m precision) makes full backup impractical, prompting cost‑driven design.

Key challenges include identifying which front‑end pages (home, channel, store‑detail) are transaction‑blocking and cannot be degraded, and understanding the underlying data‑flow dependencies for each page.

For home and channel pages, data heavily depends on GIS grid fences (3 km, 2 km, 1 km). Replicating the entire recommendation pipeline is infeasible, so a generic account strategy is used for backup, sacrificing some personalization but ensuring data consistency.

Store‑detail pages rely on search and classification services. Classification data is relatively static, while product data changes frequently. A selective caching approach (full cache for classifications, selective cache for products) reduces storage while maintaining user experience.

To drastically cut backup volume, a grid‑based approach is adopted. By constructing H3 hexagonal grids (precision 7 and 8) that approximate GIS coverage, the number of POI caches drops from billions to hundreds of thousands, reducing monthly storage cost from over ¥5 million to under ¥10 000.

Hotspot POIs within each grid are identified based on user request density; only these representative POIs are backed up. Data backup frequency is tuned (e.g., daytime vs. nighttime caches) to balance experience and cost.

Client‑side caching via localStorage (~5 MB) is leveraged for home and channel pages, but not for store‑detail pages due to larger data size. A hybrid approach uses both client cache and server‑side Redis backup.

The solution includes modular components: client interaction, grid processing (using H3), task orchestration, gray‑scale rollout, and backup data switching logic. Feature flags control when client cache is used versus server backup, and fallback mechanisms handle missing data.

Finally, the article outlines broader disaster‑recovery practices such as regular backups, service redundancy (active‑passive, multi‑active), automatic/manual failover, load balancing (hardware and software), monitoring and alerting, business continuity and disaster‑recovery planning, and regular DR drills.