Skip to content

SYSTEM Cited by 1 source

Zalando Mosaic (Project Mosaic)

What it is

Project Mosaic is Zalando's first-generation micro-frontend architecture for zalando.com. Introduced in 2015 alongside Zalando's monolith-to-microservices rebuild, it let a growing number of feature teams ship independently by assembling pages from Fragments, where each Fragment is an independently owned and deployed frontend-plus-backend unit (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1).

The public reference is the open-source mosaic9 project (mosaic9.org), which documents the Fragment-based assembly model Zalando used in production.

Architectural shape

A Mosaic page is a template of slots; each slot is filled by a Fragment owned by a feature team. The Fragment is responsible for:

  • its own frontend bundle (React, Vue, or otherwise — by team choice),
  • its own backend that serves the data the fragment needs,
  • integrating with Zalando data sources,
  • rendering UI, implementing tracking, and running any A/B tests.

This mirrors the Micro-Frontends pattern at page-composition granularity and enabled Zalando to grow the website contribution surface to a large number of teams in parallel (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1).

Why Zalando moved beyond it

By 2018, four pain points were material enough to motivate a new platform (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

  1. Tech-stack / bundling / deploy divergence across Fragments led to inconsistent user experience and cross-team collaboration friction.
  2. High barrier to contribute: feature teams had to build and operate their own Fragment (frontend and backend), discover and integrate every data source, re-implement or adapt UI, and re-implement tracking + A/B testing.
  3. No centralised UX guarantees — design language, a11y, and component versioning drifted per team.
  4. Duplicated cross-cutting concerns — monitoring, consent, A/B testing, tracking each re-wired per Fragment.

These four are the exact brief for the successor Interface Framework (IF), whose unification strategy — one stack, one deployment, one design system, Entities + Renderers over Fragments — is Mosaic's negative space.

Migration state (as of March 2021)

Mosaic has not been ripped out. The successor IF's Rendering Engine explicitly supports three hybrid view shapes during migration (Source: sources/2021-03-10-zalando-micro-frontends-from-fragments-to-renderers-part-1):

  • a pure Mosaic Template using only Fragments,
  • a view that mixes Renderers and Fragments,
  • a view with only Renderers.

As of March 2021, ~90% of traffic is served via IF; the residual ~10% is Mosaic-era Fragments not yet rewritten into Renderers.

Why it matters to the wiki

Mosaic is the canonical example on this wiki of a Fragment-based micro-frontend architecture — the alternative to the entity-based page-composition model that IF introduces. The explicit post-mortem of Mosaic's pain points is the clearest available articulation of the trade-offs micro-frontend architectures incur at scale.

Last updated · 476 distilled / 1,218 read