How VIPshop Evolved from Monolithic LAMP to Distributed Service Architecture

VIPshop was founded in December 2008 and initially focused on clearing excess inventory through online outlets. After its 2013 IPO, the company shifted to a multi‑brand flash‑sale model, expanding its business scope while maintaining a core focus on brand‑supplier collaboration and consumer discount channels.

VIPshop System Architecture Evolution

Single‑Application Architecture

Characteristics: a single application deployed as a LAMP stack (PHP + MySQL). Drawbacks: high coupling, low scalability, and difficulty in deployment and maintenance.

Vertical Silo Architecture

Features:

Independent application modules

Separate deployment for each module

Database split per module (PHP + MySQL + Memcache)

Domain separation and static‑dynamic separation

Issues:

Strong inter‑module coupling and dependency

Complex interactions, sometimes direct DB access across modules

Single‑point database failures and data inconsistency

Difficult system expansion and low development efficiency

Distributed Application Architecture

Features:

Core business extracted as independent services

Service modules deployed separately

Read/write separation and sharding of databases

Extensive caching for performance

Asynchronous inter‑service communication

Current challenges:

Incomplete service granularity, making scaling hard

Severe data duplication and inconsistency across services

Weak foundational components (logging, monitoring)

Unclear service definitions with duplicated interfaces

Reliability issues under high traffic

Needed improvements:

Full service‑orientation of core systems (product, promotion, inventory, user)

Robust service framework, DAL sharding, caching components

Enhanced monitoring and logging

Asynchronous processing, rate limiting, fallback, stress testing, disaster recovery

E‑Commerce Platform Key Design

Key Requirements

The core of business architecture is to orchestrate various enterprise capabilities into coherent scenarios that achieve sales goals efficiently while managing resources with minimal cost.

Essential capabilities include multi‑terminal support, unified payment, order, product, and channel management, rapid marketing rollout, analytics, extensibility, high availability, security, performance, and team development.

Platform and Business Function Design

Design principles across three dimensions:

Content extensibility : dynamic support for diverse products and marketing activities.

Functional extensibility : unified mechanisms to add new capabilities.

System extensibility : smooth handling of massive user traffic, high availability, security, and recoverability.

Adopt a cloud‑based server architecture separating infrastructure (IaaS) and platform (PaaS) layers to improve resource sharing and maintainability.

Server side : Build a unified cloud‑mode IT infrastructure with standardized IaaS and PaaS layers.

Large‑scale architecture : Separate infrastructure from application functionality, enabling dedicated functional teams and system teams to focus on their respective concerns.

Core Model Design

Define product offering sales scenarios, core business objects, and promotion structures (target + condition + promotion + rules + exceptions).

Architecture Design and Governance

Enterprise IT Architecture Reconstruction

Shift from a reactive "response" model to an adaptive "adaptation" model, building a flexible, evolvable architecture that anticipates business changes.

The architecture comprises three layers:

Enterprise architecture : strategy, business model, and operational architecture.

Operational governance : standards and controls for implementation quality.

Evolutionary transformation : roadmap for gradual migration.

Application Architecture Reconstruction

Adopt a "platform + application" model, with a large‑application logical layer and a service bus for communication.

Logical layer uses a big‑application architecture:

Platform Technical Services

Provide standardized PaaS components (e.g., service bus) that abstract common technical requirements for business services and front‑end applications.

The service bus separates service management from business logic, using REST for client‑bus and bus‑service communication.

Protocol summary:

Clients invoke services via the bus.

The bus performs authentication and routes requests.

Service instances process requests and return results through the bus.

Both client‑bus and bus‑service use REST.

Summary

The platform + application architecture enables a SaaS‑style internal operations platform, providing unified user access, standardized IT environments, and consistent marketing data/services for third parties.

Business Service Refactoring

Reconstruct business capabilities around an operation‑centric model, defining external interface protocols, core capability domains, legacy handling, and new capability domains, while supporting multi‑tenant access.

This content is based on a presentation by senior VIPshop architect Guan Hua at the "Architect Practice Day – Spotlight on E‑Commerce" hosted by Qiniu Cloud.