# Microfrontends that let you sleep

By Valentin Galfré · Published 2026-09-09 · 5 min read · https://galfrevn.com/writing/microfrontends-that-let-you-sleep

> What it takes for eight teams to deploy independently on Latin America's highest-traffic platform without waking anyone up.

Nobody adopts microfrontends because they love them. You adopt them because a deploy on a Tuesday afternoon took down a page that half of Latin America was looking at, and the team that broke it wasn't even the team that owned it.

That was the shape of the problem on Mercado Libre's first-party retail team when I joined in 2024. Several teams shipped into the same retail surfaces. Every deploy depended on everyone else's deploy. Releases moved at the speed of the slowest team, and when something went wrong at scale, finding the owner took longer than fixing the bug.

This is not an essay about the pattern. It is an essay about what the pattern is for, and about the decisions that turned a diagram into a platform people could ship on without fear.

## The goal is not the architecture

The goal of a frontend platform is not modularity, or purity, or a nice box diagram. The goal is that a team can ship its own change, on its own schedule, and if that change breaks, it breaks only their slice, and only they get paged.

Everything else is a means. If a decision doesn't move you toward that sentence, it is decoration.

That framing matters because microfrontends are an organizational boundary before they are a technical one. You split the frontend where the teams are already split. If you split it anywhere else you get the coordination cost of a distributed system with none of the autonomy that was supposed to pay for it.

## What we actually decided

The interesting work was never in the runtime composition. It was in the seams.

**Ownership per slice.** Every part of the page had exactly one team behind it. Not a shared module with three maintainers. One team, one deploy pipeline, one on-call. When you can point at a rectangle on the screen and name who ships it, half of the incidents resolve themselves.

**A thin shell, a thick contract.** The shell owned routing, the design system, authentication, telemetry and the skeleton of the page. Slices owned everything inside their rectangle. The contract between them was small on purpose. Every shared thing is a thing that needs a coordinated release, and coordinated releases are exactly what we were trying to remove.

**Failure isolation.** A slice that fails to load renders its fallback and the rest of the page keeps working. This sounds obvious and is constantly undermined. One shared global, one synchronous script on the critical path, one slice that assumes another has already loaded, and you are back to a monolith with more moving parts.

> **Rule.** Any runtime dependency between two slices is a defect, even when it works.

**Independent deploys, really independent.** Each slice built, tested and released alone. No release train, no "we go on Thursdays". The test I used was simple: could a team ship at four in the afternoon on a Friday? You shouldn't, but the platform has to make it possible, because a platform where you can't is a platform where every deploy is a negotiation.

**Observability per slice.** Errors, performance and business metrics tagged by owner. A regression on the page is noise until you can say which slice regressed. Once you can, it is a ticket for one team instead of a meeting for five.

## What we deliberately did not do

We did not make everything a microfrontend. Some parts of the page changed together, always, and belonged to the same team. Splitting them would have added latency and ceremony to buy autonomy nobody had asked for.

We did not let each team pick its own framework. Independence of deployment is the point. Independence of technology is a tax you pay in bundle size, in hiring, and in every engineer who moves between teams. React everywhere, with the shell owning the version, was the boring answer and the right one.

We did not compose everything at runtime. The most stable slices were resolved as early as possible, and the shell only paid the cost of dynamic composition where the ownership boundary demanded it. Runtime composition is a tool for organizational independence, not a default.

## Where the standards actually travelled

You can write the architecture down. What makes it stick is the code review.

I was not anyone's manager. I was the most experienced engineer on the team and the one people came to, which is a different kind of leverage. Most of what I did that year that mattered did not ship as code. It shipped as comments on pull requests, in the same tone, about the same things, until the things became habits. Where the contract between shell and slice was, why a global was a defect, why a slice that reached into another slice's state was a bug even when it worked. Reviews are where a platform's opinions become the team's opinions, and the only scalable way I know to mentor without becoming a bottleneck.

The rest was presence. Whiteboards, a round of mate, the same room when it was possible.

> Alignment on where a boundary goes is a conversation, not a document.

## Sleep as a metric

You can measure a platform with deploy frequency, lead time, change failure rate. All good. The one I kept coming back to was quieter.

When a team on the platform ships on Friday, does anyone else lose sleep? When something breaks at night, does exactly one phone ring, and does the person holding it already know what to look at?

If the answer is yes, the architecture is doing its job. Microfrontends are a means to that. So is a contract small enough to fit in your head, and an ownership map with no gaps. The best version of this work is the one nobody talks about, because the pages are fast, the deploys are boring, and everyone slept.