Skip to content

Architecture Upgrade in Practice: Building an Industry-Leading Mid-to-Large E-Commerce Business Mid-Platform

About 692 wordsAbout 2 min

2025-10-11

Staging demos:

Ops analytics mid-platform (account/password: speed2025)

User-facing H5 mall

To clean up legacy issues left by prior outsourcing, we reworked the overall system architecture.

Tech stack and architecture changes

To replace the old tightly coupled frontend/backend that slowed delivery and limited UI/UX, we rebuilt on a modern full-stack open-source stack (Vue 3 + Element Plus + Laravel).
The old platform and agent portals were separate modules with low reuse — the same logic needed multi-place edits, large code volume, and easy bugs. The new ops mid-platform unifies roles into one codebase, with RBAC at button-level permissions and a CRUD code generator, significantly raising mid-platform delivery speed.

Low-invasiveness refactor

To use data for ops decisions while sharing the database with the old system — without a full understanding of every corner — we chose the least invasive path:

  • Compute key metrics at the DB layer via database Views;
  • Join multiple View “virtual tables” through the ORM to cover a dozen e-commerce KPI reports quickly;
  • Vs. scheduled jobs materializing many physical report tables (space for time), Views win when volume is moderate: near-zero lag, high flexibility (change View definitions without re-running scripts to fix data).

Homegrown product exposure collection

To capture interest and exposure→conversion rates, we compared commercial SDKs (Sensors Data, GrowingIO, etc.) — feature-rich but costly. We chose a homegrown approach, borrowing effective-exposure definitions from vendor docs:

  • Use the browser Intersection Observer API for product exposure;
  • Count “effective exposure” only when the user truly sees the product (visible ≥ 50% and dwell ≥ 5 seconds);
  • Support timed and batched reporting to avoid request and network load.

Virtual product pools and automated ranking

To let ad campaigns customize catalogs, ranking, categories, and even layout elements per audience (for A/B tests, etc.), I proposed and built virtual product pools:

  • On top of thousands of listed SKUs, add an abstraction: unlimited virtual categories and pools, flexibly bound to that day’s campaign audience packs;
  • Technically: multiple ORM association models and complex relationships.

Manual ranking of large catalogs was slow and ineffective, so we built automated ranking from traffic and sales reports:

  • Jobs read performance reports, filter noisy metrics, and refresh order on a schedule;
  • After several progressive iterations, the system stabilized with full auto-ranking plus human override.

UI/UX and observability

We invested heavily in mid-platform UI/UX, for example:

  • Drag-and-drop category ordering;
  • Cross-page multi-select / invert-select across paginated tables.

Because the backend runs many automated behaviors (technically opaque), we stressed system observability so hidden bugs would not mislead ops:

  • Clear provenance of final numbers;
  • Cross-checks in multiple places;
  • Live preview of virtual product ranking (matching real user views) and quantified ranking inputs — building ops trust in system behavior.

Ops and security

To support growth, we changed ops architecture:

  • Multi-host deploy; backend traffic via ALB (Application Load Balancer);
  • Frontend static assets (code, images) on OSS with CDN;
  • Open-source release system SPUG for Git multi-branch fast ship and rollback — parallel development, testing, and isolated environments.

Monitoring and security:

  • Centralize business and web logs, alert rules, live availability and KPI monitoring;
  • After CDN abuse/bandwidth attacks, upgrade to WAF-backed EAS edge acceleration;
  • External white-hat penetration testing; fixed SQL injection, privilege escalation, XSS, Cookie issues, and more;
  • Framework-level API rate limits against scripted brute force; admin login entry path randomly encoded (internal-only, rotatable) for security.

Summary

Without invading the old system at large scale, through stack choice, architecture, and process we achieved:

  • Higher delivery speed and reuse (unified mid-platform, button-level RBAC, code generator);
  • Low-invasiveness Views for KPI reports with realtime and flexibility;
  • Homegrown exposure collection and virtual pools for highly customizable campaigns and auto-ranking;
  • Stronger observability and security for ops and data reliability;
  • Fast ship/rollback and multi-host elasticity for 100k+ DAU scale.

Changelog

8/27/26, 2:41 PM
View All Changelog
  • 94b04-Quote YAML frontmatter descriptions containing colons.on
  • 68955-Translate all 14 blog posts to English for Plume i18n.on
  • b7b2c-启用文章变更历史并升级主题配置。on
  • b19ea-重构: 将文章迁移至 blog 目录,更新配置on
  • 9059e-upon