How We Cut Rule‑Update Cycle from Weeks to Days: A Full‑Stack Case Study

Introduction

In the e‑commerce transaction domain, management categories serve as the core vehicle for business responsibility division and coordination. As business complexity grew, rule‑adjustment frequency increased from once per quarter to multiple times per quarter, and the rule complexity of third‑level categories rose exponentially, exposing three major pain points.

Business Pain Points & Technical Challenges

Efficiency bottleneck: manual processes clash with high‑frequency iteration.

Quality risk: rule complexity outpaces validation capabilities, leading to duplicate or missing rules.

System coupling: underlying changes cause a domino effect on downstream applications.

These issues result in long rule‑submission cycles (3‑4 weeks) and delayed downstream system responses.

Technical Solution

Layered Architecture

A multi‑layer design decouples business logic from data pipelines, enabling independent evolution of each component.

Core Module Implementation

public List<ManagementCategoryDTO> buildTree(List<ManagementCategoryEntity> managementCategoryEntities) {<br/>    Map<Long, ManagementCategoryDTO> managementCategoryMap = new HashMap<>();<br/>    for (ManagementCategoryEntity category : managementCategoryEntities) {<br/>        ManagementCategoryDTO managementCategoryDTO = ManagementCategoryMapping.convertEntity2DTO(category);<br/>        managementCategoryMap.put(category.getId(), managementCategoryDTO);<br/>    }<br/>    List<ManagementCategoryDTO> rootNodes = new ArrayList<>();<br/>    for (ManagementCategoryDTO dto : managementCategoryMap.values()) {<br/>        if (Objects.equals(dto.getLevel(), ManagementCategoryLevelEnum.FIRST.getId()) && Objects.equals(dto.getParentId(), 0L)) {<br/>            rootNodes.add(dto);<br/>        }<br/>    }<br/>    for (ManagementCategoryDTO node : managementCategoryMap.values()) {<br/>        if (node.getLevel() > ManagementCategoryLevelEnum.FIRST.getId()) {<br/>            ManagementCategoryDTO parent = managementCategoryMap.get(node.getParentId());<br/>            if (parent != null) {<br/>                parent.getItems().add(node);<br/>            }<br/>        }<br/>    }<br/>    return rootNodes;<br/>}

Rule Lifecycle Management

Operations include Add (id null), Delete (existing DB rows not in the submitted list), and Update (name or rule changes trigger different approval flows). The state machine ensures cascading status changes: a draft at a higher level blocks edits to lower levels, and vice‑versa.

Approval Workflow

Four submission scenarios—name change, first‑level addition, rule modification, and activation/deactivation—are routed through a dynamic, multi‑level approver chain. The approver map is built programmatically:

public Map<String, List<String>> buildApprover(ManagementCategoryDraftEntity draftEntity, Map<Long, Set<String>> catAuditorMap, Map<String, String> userIdOpenIdMap, Integer hasApprover) {<br/>    Map<String, List<String>> nodeApprover = new HashMap<>();<br/>    if (!Objects.equals(hasApprover, ManagementCategoryUtils.HAS_APPROVER_YES)) {<br/>        nodeApprover.put(ManagementCategoryApprovalField.NODE_SUPER_ADMIN_AUDIT, queryApproverList(0L, catAuditorMap, userIdOpenIdMap));<br/>        return nodeApprover;<br/>    }<br/>    Integer level = draftEntity.getLevel();<br/>    Integer draftType = draftEntity.getType();<br/>    boolean isEdit = ManagementCategoryDraftTypeEnum.isEditOp(draftType);<br/>    List<Integer> approvalChain = buildApprovalChain(level);<br/>    for (int i = 0; i < approvalChain.size(); i++) {<br/>        int currentLevel = approvalChain.get(i);<br/>        Long categoryId = getCategoryIdByLevel(draftEntity, currentLevel);<br/>        String nodeKey = String.format(ManagementCategoryApprovalField.NODE_LEVEL_X_ADMIN_AUDIT_TEMPLATE, currentLevel);<br/>        if ((isEdit && currentLevel == level) || currentLevel != level) {<br/>            addApprover(nodeApprover, nodeKey, categoryId, catAuditorMap, userIdOpenIdMap);<br/>        }<br/>    }<br/>    return nodeApprover;<br/>}

Data Model Design

The management‑category entity includes fields for level, parentId, rule list, and status. A tree structure is built to represent hierarchical categories, and rules are attached to leaf nodes.

Data‑Warehouse Calculation Logic

Two computation schemes were evaluated:

Scheme 1: Trigger offline SQL jobs after each rule change. High resource consumption during batch updates.

Scheme 2: Periodic offline tasks that aggregate changes. Lower resource peaks but limited real‑time responsiveness.

Given the low frequency and clustered nature of rule changes, the periodic task approach was selected, achieving an 80 % reduction in ODPS resource usage and a 20 % increase in validation coverage.

Project Outcomes & Technical Value

Rule‑update cycle shortened from weekly to daily (1‑2 days).

First‑ and second‑level category changes require zero development effort.

Third‑level changes reduce manpower cost by 100 %.

Automated validation eliminates duplicate/omitted rules.

Real‑time downstream notification via Feishu cards replaces manual alerts.

Future Optimization Directions

AI‑driven rule‑conflict prediction to pre‑empt high‑risk changes.

Integration with Flink for real‑time computation of category‑product relationships.

Conclusion

The core value of the management‑category online‑configuration project lies not only in technical efficiency gains but also in empowering business users to become strategy designers rather than mere rule submitters. A responsive, automated toolchain unlocks creative capacity and sustains competitive advantage in fast‑moving e‑commerce markets.