How to Slash LBS Disaster‑Recovery Costs by 99% with Smart Grid Backups

Disaster Recovery in SOA Systems

In service‑oriented architecture (SOA) systems, disaster‑recovery capability is essential for stability. Deploying multiple data centers, automated failover, and data backup can greatly improve recovery when disasters occur. For example, master‑slave replication and active‑active architectures ensure other data centers take over if one fails.

Problem Background

With the launch of the “秒送” (instant delivery) business, LBS‑based user transaction traffic has increased. Unlike B2C scenarios, O2O resources are divided into fine‑grained zones (3 km, 2 km, 1 km) around stores, forming a complex LBS resource network. The backend SOA service must distinguish real‑time and near‑real‑time data to define backup strategies, understand data production pipelines, and ensure backup data authenticity and user experience.

Pain Points / Challenges

1. Caching POI latitude‑longitude data

National POI count at 75 m precision exceeds 680 million; at 1 m it would be over a trillion. Backing up every POI would require about 1,646 TB of storage, costing over 5 million CNY per month, which is unacceptable.

2. Reducing storage cost

Monthly storage cost of several million CNY is unrealistic; a balance between user experience and cost is needed.

3. Ensuring cache data validity

Data consistency is critical. Real‑time backup would overload RPC queries, while asynchronous methods require replicating complex search, recommendation, and GIS logic across thousands of middle‑platform message queues.

Industry Solutions Survey

We consulted peers and learned that some companies rely entirely on lower‑layer data without their own backup, highlighting the difficulty of finding a ready‑made solution.

Proposed Solution

1. Identify non‑degradable entry points

Home page, channel page, and store‑detail page are transaction‑blocking and require backup.

2. Analyze underlying data dependencies

(1) Home & Channel Pages

These pages use CMS and targeted delivery systems to filter content based on LBS. Core resources depend on recommendation system data, which varies with user location and strategy, making exact backup impossible. We adopt a generic account with standard strategy to reduce variability.

(2) Store‑Detail Page

Store classification and product data come from search and merchant middle‑platform services. Classification changes slowly, while product status and inventory change frequently. We propose full‑cache for store classification and selective cache for products.

3. Reduce backup data volume

Home and channel pages require complex POI‑related backup; store‑detail page is simpler.

(1) Home & Channel Pages – Grid Concept

GIS maintains grid fences (3 km, 5 km, 20 km). Building a similar grid to cache store products can greatly reduce data size. Directly caching POI‑level recommendation results avoids replicating recommendation logic.

(2) Grid Construction

We evaluated various spatial indexes (Mercator, geohash, H3, S2) and chose H3 for the demo. Using H3 hexagonal grids with resolution 7 (≈1.4 km edge) yields about 300 k hotspots, reducing data volume by 99 % compared with raw POI backup.

Cost after compression: resolution 7 – 2,973 CNY/month; resolution 8 – 14,133 CNY/month, versus the original >5 million CNY/month.

(3) Store‑Detail Page

Cache top two pages of products for each leaf category, exclude closed stores, reducing cost to about 900 CNY/month.

4. GZIP Compression

Compressing all data as strings with GZIP saves ~60 % space. Backup size and cost before and after compression:

Home page: 1087 GB → 652 GB, cost 2,973 CNY/month → 1,956 CNY/month.

Channel page: 3,624 GB → 2,174 GB, cost 14,133 CNY/month → 6,522 CNY/month.

Store‑detail page: 300 GB → 180 GB, cost 540 CNY/month.

Total cost reduced from >5 million CNY/month to about 9,018 CNY/month.

5. DIFF Verification

(1) Home & Channel Pages

We select seven POIs (six vertices and center) per hexagon to request online data and compute a diff ratio; sampling 10 groups in 39 cities yields a coverage metric to choose optimal grid resolution.

(2) Store‑Detail Page

Key stores are periodically checked; if diff error exceeds 30 %, a new data‑generation task is triggered.

Implementation

1. Client Interaction Module

Client caches data in localStorage (~5 MB). When the server detects an anomaly, it can fall back to the client cache if it is recent; otherwise it serves backup data from Redis.

2. Grid Module

Using the JMF component, we generate H3 grids at resolutions 7 and 8, store hotspot POI coordinates in MySQL for workers.

3. Task Module

Handles data generation with attention to RPC pressure, retry mechanisms, and alerting.

4. Gray‑Release Module

Includes pressure testing and staged rollout by pin, store, and city.

5. Disaster‑Recovery Data Switch

Home/Channel pages: if client cache is valid, use it; otherwise fetch backup Redis data. Store‑detail page: if class tree is empty or product list missing, fall back to backup Redis data.

Effect Demonstration

Images illustrate before‑and‑after storage and cost metrics for home/channel and store‑detail pages.

Reflection

The LBS‑scenario disaster‑recovery data‑backup solution dramatically cuts cost while maintaining high availability. Future work includes building automated failover mechanisms for even faster incident response.