Overview
Familhão is a subscription platform with discount coupons, credits redeemable for products and services, and monthly prize draws. Achou Levou is one of the areas in that ecosystem. The product brought together very different journeys (login, payments, the Família area and Achou Levou's offers) that all had to feel like one experience to the user.
Challenge
When I joined, the application was not split into microfrontends yet. Several teams were working on different areas at the same time and needed to build, test and release without waiting on a single release train. Splitting the app solved autonomy but created a new problem: keeping the pieces working as one product (same session, same navigation, same visual identity) without coupling modules to each other.
My role
- Took part in the architecture discussions, the migration strategy and the implementation of the microfrontends with Single-SPA and Module Federation.
- Owned the Achou Levou MFE and the Design System shared across modules.
- Worked on the other MFEs on integrations, architectural changes and problems that cut across modules.
- Helped define the frontend technical standards the teams followed.
Architecture
A host and around 7 microfrontends
A host orchestrates the modules: login, payments, Família, Achou Levou and other areas. Single-SPA handles each MFE's lifecycle (activating it by route, mounting and unmounting). Module Federation loads remotes at runtime and shares dependencies such as React, so each module doesn't ship its own copy.
A shared-state API
State that had to cross module boundaries (user data, session and auth, journey data and signals between MFEs) sat behind an in-house API. Each microfrontend read and updated it through that API instead of importing Redux, Zustand or any store directly. The internal implementation could change without breaking consumers, and no module was tied to another module's choice of state manager.
The Design System as a visual contract
With several teams shipping independently, visual consistency could not rely on discipline alone. The shared Design System standardized components, behavior and identity across modules and cut down on components being rebuilt in each MFE.
Key decisions & trade-offs
Why microfrontends
The main driver was organizational: several teams needed to ship their areas without coordinating a single deploy. The autonomy came with more integration complexity. Keeping React and shared dependency versions compatible, avoiding duplicate libraries in the bundle, navigating between modules, CSS conflicts and initial load all became architecture problems rather than per-screen ones.
Shared state through an API, not a store
A shared global store would have been simpler at first, but it would have tied every MFE to the same library and version. The API added a layer to maintain and forced us to be strict about what was really global. In return, each module could evolve its internal state without affecting the others.
Single-SPA and Module Federation together
Each tool covers part of the problem. Single-SPA orchestrates lifecycle and routing between applications. Module Federation handles runtime loading and dependency sharing. The cost is configuring and maintaining both and keeping shared versions compatible across teams.
Results
- The application was reorganized into around 7 microfrontends, each area deployable on its own.
- Teams could build, test and ship their modules without waiting on a single release.
- Session and user data were shared across modules without coupling them to a state library.
- The Design System reduced visual inconsistencies and duplicated components across MFEs.
Role
Frontend · microfrontend architecture and Design System
Tech stack
- React
- TypeScript
- Single-SPA
- Module Federation
- Design System