Micro‑Frontend Architecture for Dada Express Operation System: Challenges and Solution

Background

Dada Express's operation system is assembled from multiple business‑line subsystems. Rapid business growth caused the number of subsystems to explode, increasing complexity: from 3 subsystems at creation in March 2018 to 15 subsystems by March 2021.

Problem

Because each subsystem follows a different iteration cycle, the operation system deploys daily, resulting in queued deployments, inability to roll back, and slow builds.

Queued deployments: Night‑time deployments show a clear waiting line between the 1st and 5th releases, affecting not only the front‑end but also back‑end, testing, and product teams.

Unable to roll back: When a problem is discovered the next day, the only option is to revert code changes and redeploy, prolonging the issue.

Slow builds: Even unchanged subsystems must participate in the full packaging process, and more subsystems mean longer build times.

Severity in March 2021:

1. 21 queued night‑time deployments 2. 28‑minute rollback via redeployment 3. 482 builds with an average of 10 minutes each

Goal

Address the three pain points:

1. Reduce queued deployments 2. Enable direct rollbacks 3. Accelerate build speed

Transform the current diagram into the target diagram (see image).

Problem Analysis

The root cause is that the front‑end of the operation system follows a monolithic architecture; all subsystems must be packaged together for deployment.

When a subsystem fails, the whole system must roll back, so teams queue deployments: deploy one subsystem, wait ten minutes, then deploy the next.

This leads to a situation where rolling back a middle deployment removes all later features, so teams avoid direct rollbacks and instead revert code changes and redeploy.

Every deployment packages all subsystems, even unchanged ones, causing build time to grow with subsystem count.

Solution Comparison

Splitting the monolith into independent applications would solve the problem, but would reduce development efficiency and break product interaction experience.

Problems of splitting:

1. Development efficiency drops because code reuse becomes difficult; shared code now lives in separate repositories and must be packaged as dependencies.

2. Product interaction suffers: URLs change, navigation patterns shift, leading to broken links and noticeable white‑screen flashes.

Therefore, we need a runtime aggregation that decouples development while preserving a unified user experience—this is the essence of micro‑frontend.

Micro‑Frontend Solution

By partitioning subsystem boundaries with a micro‑frontend architecture, overall system complexity is isolated to each subsystem, preventing engineering coordination issues caused by differing iteration cycles.

Constraints

Do not reduce development efficiency:

1. Avoid making code reuse harder.

Do not break product interaction experience:

1. Existing links must remain functional. 2. Avoid obvious white‑screen flashes during navigation.

Do not require excessive manpower:

1. Infrastructure already has multiple environments and complex pipelines. 2. Business development schedules are tight; splitting costs must be low.

Solution Selection

Front‑end rendering can be classified into three categories (six types): server‑side rendering, browser rendering, and hybrid server‑rendered rendering.

Server rendering uses backend templates; switching between apps relies on backend routing.

Browser rendering uses modern frameworks like React or Vue; the initial HTML is empty and JS populates the UI. App switching can be backend‑route‑based (load another HTML) or front‑end‑route‑based (load another JS bundle).

Service‑side rendering (SSR) renders the first view on the server for fast first paint, then runs JS in the browser for interactivity. Switching still follows backend or frontend routing.

Our operation system currently uses browser rendering (highlighted in red). Changing to server rendering would break interaction experience; switching to SSR would require too many resources. Therefore, the rendering mode must stay unchanged.

Within browser rendering, backend routing would also break experience, so front‑end routing (highlighted in green) is the most suitable, adding only one extra front‑end router layer.

Technical Trade‑offs

Two popular solutions exist:

1. The open‑source single‑spa framework (foreign). 2. The domestically adapted qiankun framework built on single‑spa. They differ in many aspects; selection must match business scenarios—no silver bullet. Service Registration and Discovery After splitting a large app into many small apps, we need a way to locate each app's dynamic file URLs, similar to backend service registration/discovery. Using Import Maps and ES modules (or SystemJS as a polyfill) enables front‑end service registration and discovery. Single‑spa typically uses es‑module‑shims or SystemJS; for new projects we modify the main app's build config, while cloned sub‑apps need no changes. Qiankun’s HTML‑based approach avoids build‑tool changes but requires specifying HTML URLs per environment, adds extra payload, and needs a parser, which hurts load performance. Given mobile devices dominate (>60%), Import Maps + ES modules is preferred to keep page load fast and avoid white screens. Version Control and Pre‑loading Shared modules across apps should be extracted to avoid duplicate builds and loads, and allow different apps to use different versions of the same module. When dependencies are known, we can pre‑load them to solve the waterfall problem and optimize the critical rendering path, especially for high‑frequency apps. Import Maps scopes handle versioning; SystemJS depcache handles pre‑loading. Variable and Style Isolation Running multiple apps in the same browser context can cause interference; isolation is needed for both single‑app and multi‑app scenarios. Single‑app isolation uses snapshot techniques: save the global state before mounting and restore after unmounting; remove injected styles on unmount. Multi‑app isolation uses sandboxing: create a separate execution context via new Function and Proxy, and isolate styles via one of three methods: 1. Append random strings to style names. 2. Use data‑attribute selectors (similar to deprecated scoped CSS). 3. Employ Shadow DOM for full DOM isolation. Variable isolation is mature; style isolation requires case‑by‑case decisions. For single‑app we can snapshot styles; for multi‑app, Shadow DOM offers the best trade‑off without renaming styles and handles CSS animations well. Final Solution After comparison, the chosen solution builds on the open‑source single‑spa framework and customizes it for our scenario: 1. Implement service registration and discovery with Import Maps and SystemJS. 2. Use Import Maps scopes and SystemJS depcache for version control and pre‑loading. 3. Employ single‑spa as a framework‑agnostic front‑end router for traffic distribution. 4. Achieve variable isolation via a mature sandbox implementation. 5. Combine snapshot and sandbox techniques for style isolation. 6. Enable inter‑app communication through browser custom events. With the solution confirmed, the next step is concrete implementation.