Imagine a dashboard page. Your state might look like this:

// A simplified state representation in a Zustand/Redux-like store
{
  page: 'dashboard',
  mfeStatus: {
    'profile-header': 'loading', // This one is currently fetching data
    'activity-feed': 'idle',     // This one is waiting to be triggered
    'recommendations': 'idle',   // This one is also waiting
    'main-nav': 'success'      // This one loaded instantly
  }
}

By centralizing this, the application shell can now make intelligent decisions. For example, it could show a single, elegant skeleton loader for the sections that are `loading` instead of a dozen individual spinners.

Step 2: The Command Bus for Cross-MFE Communication

Direct communication between MFEs is an anti-pattern. It creates a tightly coupled system, which is what we were trying to avoid in the first place! Instead, we introduce a Command Bus (or Event Bus).

This is a simple pub/sub system. MFEs don't talk to each other; they publish events to the bus or subscribe to events from it. This keeps them fully decoupled.

You can implement this with vanilla browser `CustomEvent`s or a tiny library like `mitt`.

// In the application shell (or a shared utility)
// This creates a global event bus
import mitt from 'mitt';
export const commandBus = mitt();

// --- In profile-header.js (MFE-A) ---
import { commandBus } from './bus';

async function loadProfile() {
  const user = await fetchUser();
  // Announce that the profile is loaded, passing the data as a payload
  commandBus.emit('profile:loaded', { user });
}

// --- In activity-feed.js (MFE-B) ---
import { commandBus } from './bus';

// Listen for the event from the other MFE
commandBus.on('profile:loaded', ({ user }) => {
  // Now we have the user ID and can safely fetch the activity feed
  fetchActivityForUser(user.id);
});

The MFEs have no knowledge of each other's existence. They only know about the event `profile:loaded`. This is a huge win for decoupling.

Step 3: The Orchestration Layer for Smart Loading

This is the controller's brain. The orchestration layer connects the state machine (Step 1) and the command bus (Step 2) to create a robust, predictable loading flow.

Its responsibilities are:

1. Listen to the Command Bus: It subscribes to critical events like `profile:loaded`.
2. Update the State Machine: When an MFE finishes loading, the orchestrator hears the event and updates the central state (e.g., `mfeStatus['profile-header'] = 'success'`).
3. Dispatch Commands: Based on the current state and dependencies, it decides what to do next. It might tell another MFE to start loading.

Let's refine our dependency example. The `activity-feed` shouldn't listen for `profile:loaded` itself. The orchestrator should.

Putting It All Together: A Practical Example

Imagine a dashboard with a `ProfileHeader`, `ActivityFeed`, and `Recommendations`. The latter two depend on the `userId` from the header.

Here's the flow with our 3-step controller:

1. Initial Load: The page mounts. The orchestrator is configured with the page's MFE dependency graph: `[ProfileHeader] -> [ActivityFeed, Recommendations]`.
2. Dispatch Initial Command: The orchestrator updates the state machine: `mfeStatus: { 'profile-header': 'loading' }`. It then dispatches a command: `commandBus.emit('load:request', { mfe: 'profile-header' })`.
3. MFE Loads: The `ProfileHeader` MFE is built to listen for its specific `load:request` command. It fetches its data and, upon success, emits a new event: `commandBus.emit('load:success', { mfe: 'profile-header', payload: { userId: '123' } })`. If it fails, it emits `load:error`.
4. Orchestrator Reacts: The orchestrator is listening for all `load:success` and `load:error` events. It hears the success event for `profile-header`.
5. Update and Propagate: It updates the state machine: `mfeStatus: { 'profile-header': 'success' }`. It sees that `ActivityFeed` and `Recommendations` were waiting for this.
6. Dispatch Dependent Commands: The orchestrator now dispatches new commands: `commandBus.emit('load:request', { mfe: 'activity-feed', context: { userId: '123' } })` and `commandBus.emit('load:request', { mfe: 'recommendations', context: { userId: '123' } })`. It also updates their status to `loading` in the state machine.

The race condition is gone. The loading sequence is predictable. The shell can use the centralized state machine to show users exactly what's happening. We've achieved orchestration without coupling.

Is This Overkill? When to Use the Controller Pattern

This pattern introduces a layer of abstraction, and it's not for every project. If you have two simple, independent MFEs on a page, you don't need this. But as your system grows, the cost of *not* having it skyrockets.

Here's a quick guide:

Conclusion: Escaping the Hell, Entering a New Era of Control

Async Microfrontend Hell is a direct result of embracing decentralization without planning for coordination. By implementing the 3-step controller pattern—a centralized state machine, a decoupled command bus, and a smart orchestration layer—you can reclaim control over your application's lifecycle.

This approach turns chaos into predictability. It makes your system more resilient to errors and provides a vastly superior user experience. Your teams can remain independent and focused on their domain logic, while the controller handles the complex dance of asynchronous loading and state management.

So the next time you see that cascade of loading spinners, don't just add another `setTimeout`. Take a step back and think about orchestration. It’s the key to moving from async hell to a well-coordinated, scalable, and truly manageable microfrontend paradise.