How Youku Engineered a High‑Performance, Low‑Latency Marketing Platform

Background

With the video‑on‑demand market reaching maturity, membership services have become saturated. Youku required a marketing platform capable of handling diverse discount, buy‑gift, claim, and grant scenarios for both internal and external business lines.

Challenges

1. Complex, variable scenarios – Four primary marketing types (discount, buy‑gift, claim, grant) involve numerous combinations across products, orders, and partner ecosystems.

2. High availability and low latency – Marketing interfaces must be fast and reliable; any delay or failure directly impacts order conversion, pricing consistency, and can trigger severe customer complaints and legal risks.

Architecture Implementation

Rule‑based engine using QLExpress

Business conditions are abstracted into rules (e.g., user group, membership level, purchase count, product, inventory). The QLExpress engine, a lightweight Java‑like rule engine, supports custom operators, functions, and macros. It guarantees thread safety via ThreadLocal and minimizes object allocation by using a cache‑pool.

Unified marketing framework and core engine

The upgraded architecture abstracts all discount capabilities into a unified model, enabling mutual exclusion, stacking, and price calculation across multiple coupon types. The core engine processes discount sequences, supports multi‑currency pricing, and outputs structured discount data for downstream transaction systems.

Key steps of the core engine:

Acquire discount request context.

Define discount models for various types.

Classify discounts to generate combination sequences.

Propagate discount calculation context.

Execute ordered price computation.

Generate result with combined discount, description, and pricing information.

Sort results and produce final discount output.

Low latency and high availability

Multi‑cache storage

Combine a local in‑memory cache with a distributed KV store. Small, frequently accessed data (rules, activity info) are cached locally and updated via real‑time broadcast. Larger user‑level data are stored in the distributed cache with persistence, reducing database load.

Multithreaded matching

Core marketing nodes (rendering, ordering, grant) run in separate thread pools sized per business type. Tasks are submitted via ExecutorService using Callable and Future for result retrieval. Typical thread‑pool parameters:

corePoolSize      // core thread count
maximumPoolSize   // maximum thread count
keepAliveTime     // idle thread retention time
unit              // time unit for keepAliveTime
workQueue         // queue for pending tasks
threadFactory     // factory to create threads (default is sufficient)

Asynchronous grant handling

After payment success, marketing grants are sent asynchronously with retry logic and idempotent identifiers, ensuring reliable delivery to Alibaba ecosystem partners.

Distributed transaction support

Critical steps use re‑entrant distributed locks identified by business rules to guarantee consistency. Inventory locks leverage MySQL row‑level locking and a server‑side queue (QUEUE_ON_PK) to reduce kernel mutex contention.

Conclusion and Recommendations

Design a generic, flexible, and extensible architecture to accommodate evolving marketing needs.

Achieve high availability and low latency through multi‑dimensional optimizations: caching, multithreading, asynchronous processing, retry mechanisms, and scoped locking.

Match design patterns to business complexity—simple scenarios use straightforward patterns, while complex cases require holistic performance tuning.