Notino's monolithic storefront slowed pages and releases. Microfrontends and reorganized teams made it 60% faster with ten times the request capacity.
Project facts
Every engagement rests on a few checkable facts.
- Our role
- Consulting and development
- Industry
- E-commerce
- Technology
- Microfrontends · E-commerce platform
- Services
- Custom software development
One tightly coupled application slowed a global storefront
Notino sells beauty and fragrance online across many markets, from a broad catalog. For a shopper, a slow page or a broken release is part of the same experience as finding the right product.
The storefront ran as one monolithic application. Pages loaded slowly, errors were frequent, and every frontend change traveled through the same release path. The customer base kept growing. The application did not keep up.
Shoppers needed faster pages and fewer broken releases
- Faster page delivery across a broad catalog
- Releases an international operation could rely on
- Room for more requests as the customer base grew
The monolith tied every team to one release
- Frontend work coupled to the whole application
- Performance delays and frequent errors
- Release dependencies that decided how often teams could ship
We split the frontend, then rebuilt the teams around the split
We designed a microfrontend architecture: the frontend divided into parts that separate teams develop and release on their own, with far less dependence on the monolith. Delivery continued while the parts were carved out one at a time.
Architecture alone would not have changed how often Notino shipped. We reorganized the frontend teams around the new boundaries so that each area had an owner and a release path of its own. Speed, error rate and request capacity were treated as one problem with the team structure, not as a tuning exercise on the side.
Each frontend area ships on its own
Frontend areas became independently deliverable parts. A change in one area no longer had to wait for, or risk, a release of the whole storefront.
Team boundaries follow the technical ones
Teams were reorganized so the architecture could carry more frequent releases. The wider e-commerce platform stayed in place; the frontend stopped depending on its monolithic release.
Faster pages, more capacity, more releases
- Page speed
- 60% improvement
- Request capacity
- 10 times more requests per minute
- Release frequency
- 10 times more frequent releases
The numbers describe a period of change, not one fix
The project record reports a 60% improvement in page speed, capacity for 10 times more requests per minute, 10 times more frequent releases, and fewer bugs after the change.
The figures cannot be attributed to a single technical change. They come from a period in which the architecture, the development practices and the team structure changed at the same time.
Similar work, a different starting point
A description in your own words is enough to start.
Describe what is holding you back. Within two business days we get back to you with a first practical step.