Atmosphere Center Architecture and Configuration Management

This article introduces the concept of “Atmosphere” in Taobao’s marketing system and explains why an Atmosphere Center is required.

Atmosphere is a visual expression that stimulates consumer purchase intent, usually tied to discounts or pricing. The center decides which content to display at which page position based on rules.

The overall architecture consists of a front‑end configuration portal, a back‑end logic layer, and a two‑side package that synchronizes configuration via the Diamond configuration service. High QPS demands local calls; the configuration is pushed to Diamond using ScheduleX and guarded by a Redis global lock.

Two configuration portals exist: Portal A maps rules to positions, while Portal B adds time‑based activity dimensions for large‑scale promotions. Both are needed because they address different use cases.

The configuration pipeline flows from the front‑end through applications M and B, persisting data in a TDDL database. Each record stores both a regular form object and a serialized Diamond configuration, which is periodically pushed by ScheduleX.

Handler classes use an abstract BaseHandler to perform CRUD on the form data, while subclasses implement effect methods to update specific Diamond entries. Example snippets:

public abstract class BaseHandler{
  public Result
add(Request request, boolean effect) {
    // modify form via DAO
    // custom logic to update Diamond
    if (effect) { effect(request); }
  }
  protected abstract void effect(T t);
}

public class AHandler extends BaseHandler{
  @Override
  protected void effect(ADTO dto) {
    Result
result = AManager.saveA2Diamond(dto);
  }
}

Requests to the two‑side package contain a handler identifier and an operation type (add, detail, list, etc.). A typical JSON payload is shown.

{
  "environment": "pre",
  "businessCode": "code",
  "handleType": "modify",
  "id": 0,
  "content": { ... }
}

The package retrieves applicable Atmosphere items from Diamond, filters them by global and custom rules (expressed as tree structures with AND/OR nodes), and performs post‑processing such as mutual exclusion and dynamic text substitution using StrSubstitutor .

Key takeaways: dual configuration portals, synchronized Diamond storage, abstract handler design, and dynamic content generation. Future work includes consolidating the portals, optimizing Diamond usage, and refactoring increasingly complex custom logic.