How Virtual Phone Numbers Reinvent Trust and Resilience in E‑Commerce Services

Introduction

In the era of booming digital consumption, personal data leakage has become a hidden threat to e‑commerce. Fraudsters exploit order information to impersonate customer service or logistics, harming consumer rights. Privacy numbers—virtual phone numbers assigned per order—replace real phone numbers throughout the internet chain, providing data isolation and compliance with personal information protection regulations.

What Is a Privacy Number?

A privacy number, also called a virtual phone number, is a telephone number not bound to a physical device, typically provided by telecom operators or cloud communication services. It can forward or redirect calls and messages to actual numbers, devices, or applications, and is widely used for privacy protection, customer service, and marketing.

Features

1. Privacy protection
   * Users can use a privacy number without revealing their real number, protecting personal privacy.
   * Common in online transactions, social media, dating platforms to prevent harassment.
2. Customizability and flexibility
   * Users can set the purpose of the privacy number (call forwarding, SMS reception, etc.).
   * Numbers can be dynamically allocated and reclaimed to meet various business needs.
3. Multi‑location coverage
   * A privacy number can cover multiple geographic locations, allowing enterprises to display local numbers and increase customer trust.
4. Cost efficiency
   * Reduces international call and roaming costs.
   * No need to purchase or maintain additional physical equipment.

Deployment Modes

The main modes are AXB, XB, AX, and BY, with AXB and XB being the most common.

AXB mode: a middle privacy number X connects two real numbers A and B.

A calls X, the system forwards the call to B’s real number.

B calls X, the system forwards the call to A’s real number.

This ensures that both parties communicate via X without knowing each other's real numbers.

XB mode: a single privacy number X hides the real number B, used for one‑way privacy protection.

A calls X, the system forwards the call to B’s real number.

B’s number remains hidden from A, who only knows X.

Platforms That Need Privacy Numbers

Door‑to‑Door Recycling – First Version

Background

1. Unable to protect privacy of users/engineers.
   * Engineers may commit fraud.
   * Engineers may cancel orders after seeing low price.
   * Lack of evidence for dispute resolution.
   * Inconsistent professional communication.
2. Unable to monitor contacts (calls, SMS) between engineers and users.
   * Post‑order dissatisfaction may lead to private conflicts.

Introducing virtual numbers can mitigate these issues.

Flowcharts

Service‑Oriented Refactoring

Background

1. Poor process design
   * Cache adds complexity without performance gain.
   * Number‑pool logic is complex, causing latency and manual degradation.
   * Missing unbind/renewal logic for virtual numbers.
2. Bad database schema
   * Redundant tables, missing key fields, multiple queries, performance impact.
   * Improper index settings.
3. Bloated code
   * Tight coupling with door‑to‑door logic, hard to maintain.
4. Lack of monitoring and alerts
   * Issues rely on manual reporting.
5. Business expansion
   * Need to expose virtual number functionality as a service for other scenarios.

Implementation

New System Flow

Effect

Disaster‑Recovery System Construction

Background

Problem: Relying on a single service provider makes the virtual‑number service unstable; any provider outage blocks all related business.

Solution: Integrate multiple providers and build an in‑house disaster‑recovery system that supports one‑click downgrade/recovery, with monitoring and alerts to enable automatic failover.

System Architecture

Monitoring

Alerting

Automated Operations

Based on monitoring alerts, callback functions are configured so that when thresholds are reached the system automatically triggers provider downgrade or recovery.

Effect

Overall Summary

The system evolved through three stages: an initial AXB‑based prototype that solved data leakage but suffered single‑point failures; a service‑oriented refactor that decoupled core capabilities and scaled order volume dramatically; and a disaster‑recovery architecture with dual‑active nodes, real‑time monitoring, and automated failover that raised availability to 99.99%.

Key lessons include tolerating reasonable technical debt early, letting business scale drive upgrades, and turning each incident into an improvement opportunity by adding new monitoring items, thereby continuously enhancing system resilience.