How We Delivered a High‑Risk Digital RMB Front‑End Project Fast and Safely

Preface

The digital RMB activity, a joint effort between JD.com and local governments, covered registration, lottery, result query and offline QR‑code scanning in three cities, generating about 60 million page views. The front‑end team had to deliver quickly while managing high financial risk.

Project Characteristics

High‑Value : Each winning user could receive up to ¥238, creating strong incentive and high complaint risk.

Urgent : Tight schedule and last‑minute requirement changes left only 1–2 days for iteration.

Volatile : Six major requirement changes, including a large feature cut, required constant risk reassessment.

Prerequisites for Fast Delivery

Rapid delivery depends on thorough upfront analysis and architecture design.

Clarify Activity State Flow

A complete state machine was drawn, separating abnormal states from the core flow (registration → audit → lottery). The resulting diagram reduced cognitive load for developers.

Aggregate Data Flow with MobX

All critical data were stored in a top‑level MobX store. Components receive data via actions, avoiding direct parent‑to‑child mutations. This centralised approach eliminates chaotic data passing and simplifies maintenance.

Decouple by Need: UI Duplication, Logic Reuse

UI structures for different visual variants were duplicated, while shared logic was extracted into reusable modules. This kept components loosely coupled and easier to evolve.

Risk‑Control Measures

Risk was addressed from three angles—reducing the number of risks, lowering failure probability, and limiting impact scope—based on the nPRT risk‑expectation model.

Reduce Risk Count: Control Releases

Standardise requirement intake, evaluate necessity, and record decisions to raise the change threshold.

Separate operational content (managed via PPMS) from business logic, allowing content updates without redeploying code.

Lower Failure Probability: Fast‑Track Checks

A pre‑release checklist covering generic and project‑specific items was created to catch known risks early.

Limit Impact Scope: Module Isolation

A module loader was introduced to dispatch header components based on context, implementing a strategy‑pattern switch.

class Header extends React.Component { /* ... */ }

class HeaderModuleLoader extends React.Component {
  render() {
    let Content;
    switch (headerType) {
      case 'a': Content = <HeaderA/>; break;
      case 'b': Content = <HeaderB/>; break;
      default: return <HeaderC/>;
    }
    return (<div className='header'><BaseHeader/>{Content}</div>);
  }
}

Define Deployment Layers

The front‑end was split into four independently deployed pages: core activity page, external H5 page, app‑download page, and error page. Communication occurs via URL parameters, isolating failures.

Shorten Failure Impact Time

Monitoring SDK was later added to track interface availability, performance, and runtime errors, enabling rapid detection and response to anomalies such as traffic‑surge pages.

Conclusion

By performing detailed state analysis, centralising data management, duplicating UI while reusing logic, applying modular loading, layered deployment, and proactive monitoring, the front‑end team balanced rapid delivery with rigorous risk control. Ongoing work focuses on automating these practices and integrating them into a digital platform to further improve resilience for high‑traffic interactive events.