Service Management Platform

Overview

Service Management Platform is an enterprise-scale aviation operations ecosystem built for Universal Weather and Aviation. The platform's core technical differentiator is its Micro Frontend architecture using Webpack Module Federation—multiple domain teams build and deploy their features independently, while a centralized shell application ensures the end user experiences a seamless, cohesive product.

This isn't a simple single-page application with code splitting. It's a distributed frontend architecture where independently built, tested, and deployed modules compose at runtime into a unified platform. The shell application acts as the orchestration layer, managing cross-cutting concerns like authentication, routing, shared state, and design consistency so that domain teams can focus purely on their business logic.

The platform serves aviation professionals who coordinate real-time flight services, ground handling, and booking operations—workflows where reliability and data accuracy are non-negotiable.

Business Context: Scalable Enterprise Service Management

Universal Weather's frontend had grown to the point where a single monolithic React application couldn't support the velocity of multiple engineering teams working across different aviation service domains. Deployments became bottlenecks—one team's release blocked another's. Shared code created implicit coupling, and conflicting PR merges slowed everyone down.

The core problem: A monolithic frontend architecture created deployment coupling between teams that had no business-logic dependency on each other. A ground handling team's feature release shouldn't require coordination with the booking team's sprint cycle.

Stakeholder perspective:

• ›Engineering teams needed deployment independence—the ability to ship features on their own cadence without cross-team merge conflicts or coordinated release windows.
• ›Aviation operations staff needed a unified, fast, reliable interface—they shouldn't notice that the platform is built by different teams using different release cycles.
• ›Platform architects needed governance—ensuring that team independence didn't devolve into inconsistency, duplicated patterns, or accessibility regressions.

Constraints that shaped the architecture:

• ›Existing Sabre API integrations couldn't be rewritten; the MFE architecture had to wrap and orchestrate existing service contracts.
• ›Aviation workflows are safety-adjacent—data integrity and UI consistency aren't nice-to-haves, they're operational requirements.
• ›Teams had varying levels of frontend maturity, requiring the shell to enforce standards programmatically rather than relying on documentation alone.
• ›WCAG/AODA accessibility compliance was a legal and contractual requirement, not optional.

What I Built

1. Micro-Frontend Shell Architecture

• ›Shell as Orchestrator: Designed the host shell application using Webpack Module Federation as the platform's central nervous system. The shell owns routing (dynamically registering routes from remote MFEs at runtime), authentication (centralizing session management so MFEs never handle auth directly), and shared dependency resolution (ensuring React, Redux, and the design system load exactly once regardless of how many MFEs are composed).
• ›Runtime Module Contracts: Established typed contracts that define what each MFE must expose (entry component, route configuration, required permissions) and what the shell provides in return (auth context, theme tokens, navigation API). These contracts are enforced at build time via shared TypeScript interfaces in the monorepo.
• ›Dynamic MFE Registration: MFEs register themselves with the shell at runtime, allowing new domain features to be added to the platform without modifying or redeploying the shell. This decoupling is critical for team independence.

2. High-Performance Data & Integration Layer

• ›Sabre REST API Integration: Built resilient service wrappers around Sabre's aviation APIs, handling the complexity of their specific authentication flows, pagination patterns, and error response formats. These wrappers provide a clean, typed interface that MFE teams consume without needing to understand Sabre's API specifics.
• ›GraphQL with Apollo Client: Implemented GraphQL for complex relational queries (service availability across airports, booking histories with nested itineraries) using Apollo Client with normalized caching. The cache configuration is shared through the shell so that data fetched by one MFE is immediately available to another without redundant network requests.
• ›Layered State Management: Defined clear boundaries for state management tools—Redux Toolkit for global state that spans MFE boundaries (user session, platform settings), RTK Query for server state synchronization with automatic cache invalidation, and SWR for lightweight, MFE-local data fetching where full Redux overhead isn't justified.

3. Enterprise Component Library & Design System

• ›50+ Accessible Components: Built a comprehensive TypeScript component library using Material UI as the base layer with Tailwind CSS utility classes for layout and spacing. Every component ships with WCAG/AODA-compliant markup, keyboard navigation, screen reader support, and documented ARIA patterns.
• ›Design Token Architecture: Established a token-based theming system distributed through the monorepo, ensuring that color, typography, spacing, and elevation values are consumed from a single source of truth rather than hardcoded in individual MFEs.
• ›Form Architecture: Standardized all user input flows using React Hook Form with Zod schema validation. Form schemas are defined as shared packages in the monorepo, so validation logic is consistent whether a form appears in the booking MFE or the service management MFE.

4. Testing & Quality Governance

• ›Cross-MFE E2E Testing: Built Cypress test suites that validate complete user journeys spanning multiple MFEs—a user navigating from the booking module to the service coordination module and back. These tests run against the composed shell (not individual MFEs in isolation) to catch integration issues at MFE boundaries.
• ›Component-Level Testing: Jest and React Testing Library tests for every shared component, verifying behavior, accessibility attributes, and responsive rendering. These tests are gated in CI—a failing accessibility test blocks the PR.
• ›Automated A11y Auditing: Integrated automated accessibility scanning into the CI pipeline, catching WCAG violations before they reach code review.

5. Release & Deployment Strategy

• ›Feature-Flagged Rollouts: Implemented feature flags for progressive rollout of new MFE features, allowing teams to deploy code to production without exposing it to all users. Flags are controlled at the platform level, not within individual MFEs, maintaining centralized governance.
• ›Backward-Compatible Module Contracts: Established versioned contracts between the shell and MFEs, ensuring that updating the shell doesn't break existing MFE deployments and vice versa. Contract changes go through a deprecation cycle with clear migration paths.
• ›Independent Deployment Pipelines: Each MFE has its own GitHub Actions pipeline and Docker configuration, enabling teams to deploy on their own schedule. The shell maintains a manifest of active MFE versions, enabling rollback at the module level without affecting the rest of the platform.

Architecture Highlights

Module Federation as Runtime Composition

The key architectural decision was using Webpack Module Federation for runtime (not build-time) composition. The alternative—building all MFEs into a single bundle at deploy time—would have reintroduced the deployment coupling we were trying to eliminate. With runtime federation, the shell loads MFE bundles from their individual CDN endpoints at page load. Each MFE is a separate Webpack build that declares what it exposes and what it expects the host to provide. The shell resolves shared dependencies (React, Redux, the design system) at runtime, ensuring only one copy of each shared library loads regardless of how many MFEs are active.

Why Module Federation over iframes or Web Components: Iframes provide strong isolation but terrible performance (separate document context, no shared state, duplicated resource loading) and break accessibility continuity. Web Components would require wrapping React components in custom elements, adding complexity without clear benefit since all MFEs use the same framework. Module Federation provides the right balance—runtime code isolation with shared dependency resolution and native React interop.

Shell Governance Model

The shell enforces platform standards programmatically:

• ›Authentication: MFEs receive auth tokens through shell-provided context; they cannot implement their own auth flows.
• ›Routing: MFEs register route patterns with the shell; they cannot manipulate the browser's URL directly.
• ›Theming: MFEs consume design tokens from the shell's theme provider; they cannot define their own color or typography values.
• ›Error Boundaries: The shell wraps each MFE in an error boundary, ensuring that a crash in one module doesn't take down the entire platform.

This governance model means that even if a team makes poor architectural choices within their MFE, the blast radius is contained.

Data Flow Across MFE Boundaries

Cross-MFE communication uses a pub/sub event bus provided by the shell. When a booking is created in the booking MFE, it publishes a domain event that the service coordination MFE subscribes to for updating its view. This loose coupling avoids direct MFE-to-MFE dependencies while enabling the coordinated workflows that aviation operations require. Redux state is used for cross-cutting concerns (user session, notifications), while domain-specific state stays encapsulated within each MFE's local store.

Accessibility as Architecture

WCAG/AODA compliance isn't treated as a testing phase—it's a component library constraint. Every component in the shared library is built with accessibility as a first-class requirement:

• ›Focus management across MFE transitions (the shell manages focus when routing between MFE-owned views).
• ›ARIA live regions for real-time data updates in aviation status displays.
• ›Keyboard navigation patterns that work consistently across all MFE boundaries.
• ›Color contrast ratios enforced through design tokens, not ad-hoc color choices.

Technical Deep Dive: Webpack Module Federation Runtime Integration

The most architecturally complex challenge was making Webpack Module Federation work reliably in a production enterprise environment with five teams deploying independently.

The Problem: Module Federation's documentation covers simple cases—one host, one remote, shared React. The real-world complexity emerges when you have multiple remotes with different deployment schedules, shared state that needs to be consistent across all modules, and version mismatches between shared dependencies that need to be resolved gracefully at runtime.

Key Challenges Solved:

1. ›

   Shared Dependency Version Resolution: When MFE-A ships with React 18.2.0 and MFE-B ships with React 18.3.0, Module Federation needs to decide which version to use. The shell's Webpack configuration defines strict version ranges for critical shared dependencies, and the singleton: true flag ensures only one instance loads. The shell's version always wins, and MFE teams are required to keep their shared dependencies within the shell's declared range—enforced via CI checks in the monorepo.

2. ›

   Dynamic Remote Loading with Fallbacks: Remotes are loaded dynamically based on a runtime manifest (not hardcoded in Webpack config). If a remote MFE fails to load (CDN issue, deployment in progress), the shell renders a graceful fallback UI for that module while keeping the rest of the platform functional. This was critical for availability—a single team's deployment issue shouldn't degrade the entire platform.

3. ›

   Cross-MFE State Consistency: Redux Toolkit state is owned by the shell and provided to MFEs via a shared store. But MFEs also have local state for domain-specific concerns. The challenge was establishing clear boundaries—what belongs in the shared store (user session, permissions, notifications) versus what stays local (form state, in-progress workflows). The convention is enforced through typed slice interfaces: MFEs can read from shared slices but can only dispatch to their own domain slices.

4. ›

   Hot Module Replacement Across Boundaries: Development experience matters. Getting HMR to work across module federation boundaries (editing code in a remote MFE and seeing it update in the shell during development) required custom Webpack dev server configuration with proxy rules that route remote module requests to the correct team's local dev server.

Why this matters: Most Module Federation examples are proof-of-concepts. Making it production-ready for enterprise aviation software required solving problems that the library doesn't address out of the box—version governance, graceful degradation, state boundaries, and developer experience across team boundaries.

Key Challenges & Solutions

• ›

  Challenge: Five teams deploying independently created version drift risk for shared dependencies like React and Redux. Approach: Established a monorepo-managed shared dependency policy with version ranges enforced by CI. The shell's Webpack configuration uses singleton: true with strict version constraints, and automated checks block MFE deployments that violate the range. Why: Runtime version mismatches cause subtle, hard-to-debug issues (hooks breaking, context not propagating). Catching these at build time is significantly cheaper than debugging in production.

• ›

  Challenge: Aviation operations require real-time data consistency—a booking created in one module must be immediately visible in related service coordination views owned by a different team. Approach: Implemented a shell-provided event bus for domain events combined with Apollo Client's normalized cache sharing. When one MFE writes data, Apollo's cache updates propagate to all MFEs reading from the same cache, and domain events notify MFEs that may need to trigger additional queries. Why: Direct MFE-to-MFE dependencies would defeat the purpose of the architecture. The event bus + shared cache approach maintains loose coupling while ensuring data consistency.

• ›

  Challenge: Ensuring consistent accessibility compliance across five teams with varying a11y expertise. Approach: Baked accessibility into the shared component library so that using the standard components automatically produces WCAG-compliant markup. Added automated a11y scanning (axe-core) to CI pipelines that gates PRs. MFEs that use custom markup outside the component library must pass additional review. Why: Documentation and guidelines are insufficient for consistent compliance. Accessibility needs to be the path of least resistance—using the provided components should be easier than building custom ones.

• ›

  Challenge: Deploying a new version of the shell without breaking existing MFE deployments that haven't been updated yet. Approach: Versioned the shell's module contracts and implemented a deprecation cycle. New shell versions maintain backward compatibility with the previous contract version for a defined period, and CI flags MFEs still using deprecated contracts. Why: In a distributed architecture, you can't coordinate simultaneous updates across all teams. The shell must evolve without forcing all consumers to update in lockstep.

Outcomes

• ›Team Independence: Successfully enabled five independent engineering teams to ship features to a single production shell on their own release cadence, eliminating cross-team deployment coordination overhead.
• ›Platform Consistency: Maintained a unified user experience across all aviation workflows through the shared component library and design token architecture—aviation operations staff experience a single, cohesive product regardless of which team built each feature.
• ›Accessibility Compliance: Achieved and maintained WCAG/AODA compliance across the entire platform through the component library foundation and automated CI-level a11y testing, meeting contractual and legal requirements.
• ›Runtime Performance: Optimized load times through intelligent code-splitting at MFE boundaries, shared vendor bundle caching, and lazy loading of remote modules that aren't needed for the initial view.
• ›Operational Resilience: The shell's error boundary and fallback architecture ensured that individual MFE failures were contained and didn't cascade to affect the broader platform.

Engineering Takeaways

The Service Management Platform was a masterclass in architectural discipline over technological novelty. Micro Frontends are fundamentally a governance problem, not a technology problem. Webpack Module Federation provides the mechanism, but the real work is in defining contracts, enforcing standards, and establishing boundaries that let teams move fast without breaking each other.

Patterns I'd reuse:

• ›The shell governance model—owning auth, routing, theming, and error boundaries centrally while delegating domain logic to MFEs. This separation is what makes team independence possible without UX fragmentation.
• ›Design tokens distributed through a monorepo as the single source of truth for visual consistency. This scales far better than style guides or design documentation.
• ›The layered state management approach (Redux Toolkit for cross-cutting, RTK Query for server state, SWR for local) with clear boundaries rather than forcing everything through a single state management solution.

What I'd reconsider:

• ›The pub/sub event bus for cross-MFE communication, while effective, can become opaque as the number of events grows. A more structured approach with event schemas and a registry would improve discoverability and debugging.
• ›Apollo Client's normalized cache sharing works well but requires careful cache key management. Cache collisions between MFEs that query similar entities with different shapes can cause subtle bugs.

Trade-offs acknowledged:

• ›Chose Webpack Module Federation over build-time composition (single bundle), accepting runtime complexity in exchange for true deployment independence.
• ›Chose Material UI as the component foundation over building from scratch, accepting the bundle size overhead in exchange for a comprehensive, accessible base layer.
• ›Chose monorepo governance for shared packages, accepting the tooling complexity (workspace management, version alignment) in exchange for guaranteed consistency across teams.