Architecture and Scaling Practices of the Miaopai Short Video Platform

System Architecture Overview

The rapid growth of short‑video apps in China led to the development of Miaopai, a leading platform whose architecture is illustrated in the accompanying diagram. The top layer consists of Web and App interfaces, as well as integrations with Weibo and other partners.

Backend Technologies

Initially built with Java and MongoDB, Miaopai migrated to a PHP‑centric stack with Redis, Memcached, and MySQL to improve development efficiency and overcome MongoDB limitations. The services run primarily on Sina’s private cloud and Alibaba Cloud.

Challenges Under High Concurrency and Large Data Volumes

Rapid user growth caused 503 errors due to long PHP connection times and MySQL overload from excessive table joins and COUNT(*) queries. Solutions included moving count operations to a dedicated counter microservice, redesigning table schemas, adding indexes, and introducing redundant storage for rarely‑changed data.

Historical data accumulation without sharding led to costly DDL operations and replication delays. The team split databases by core and non‑core services, and partitioned Redis instances to balance load and isolate workloads.

Core Upload and Playback Workflow

Videos (2‑3 MB) are uploaded via HTTP. The client requests an upload endpoint, which may be a Qiniu or Sina S3 storage node. After chunked upload and merge, the storage notifies the business server to update video status, then triggers asynchronous transcoding and thumbnail generation, often offloaded to third‑party services.

Playback simply fetches the video URL over HTTP. A scheduling server validates video status and selects the optimal CDN based on real‑time regional analysis using Nginx + Lua, providing low‑latency delivery.

High‑Availability Design

Upload redundancy is achieved through multi‑cloud storage (Qiniu and Sina S3) with automatic failover. Playback employs health‑checked CDN selection; unhealthy nodes are excluded from scheduling, and fallback sources ensure continuous service.

Additional Core Components

Push notifications use custom APNS channels for iOS and a mix of Sina and third‑party services for Android, guaranteeing sub‑second delivery. Search is powered by Elasticsearch for real‑time indexing and scaling. Sensitive‑word filtering combines tokenization with Bloom filters.

Log Analysis and Monitoring

Logs (server access, error, service, app, user) are aggregated and processed by an ELK‑based real‑time analysis system, providing dashboards and alerts for rapid issue detection and service health monitoring.