Dunelm’s journey to micro frontends on AWS

Dunelm Group plc is the UK’s leading homewares retailer, with specialist offerings for customers across their superstores in the UK, and their digital platform. Dunelm’s website attracts over 400 million sessions every year and generates approximately 35% of the company’s revenue.

When an organization starts to scale, it needs to reflect their growth on the organization structure and software architecture. Often the first thought is moving from the current architecture to distributed systems. On the backend we have a consolidated architecture like microservices. But what can we do for the frontend layer, especially for companies that generate high-revenue from it?

In this blog, we will talk about how Dunelm is innovating on their digital platform with the use of a micro frontends architecture to enhance the customer experience and scale their organization.

How the journey started

Dunelm’s journey with Amazon Web Services (AWS) started in 2018, when they began re-platforming their existing ecommerce website with an event driven serverless micro-services architecture. This provided a number of benefits such as reducing the total cost of ownership and improving business agility.

However, the frontend, which was developed as a monolithic, single page application, posed a number of challenges:

Changes to the frontend required testing and deploying the whole application at once. This meant every change carried high risk and could affect any part of the website.
Dunelm were facing issues when scaling up as multiple teams worked on the website at any given time. Assigning ownership and communication between teams was becoming difficult.
The website grew in complexity and it became difficult for any single team to have deep expertise across all sections. This led to increased uncertainty when making changes, and more time spent on dealing with unexpected problems.

Due to these challenges, Dunelm experienced a steady increase in the lead-time for website changes, which had doubled. For the business to adapt quickly and respond to opportunities, a new paradigm needed to be adopted.

Objectives of a rebuild

To overcome these challenges, Dunelm needed to partially rebuild their website in a manner that did not disrupt planned feature development or the customer experience. This rebuild required substantial cost and effort.

Dunelm identified the following potential benefits they could achieve from a rebuild:

Enabling teams to take ownership of defined website areas.
Reduced lead time on changes to increase the frequency of releases.
Decreased onboarding time for newly hired developers.
Improved developer experience—increasing productivity and facilitating innovation.
Increased conversion rate and reduced bounce rate with improved website performance.
Improved website accessibility for an enhanced user experience.
Create consistency of all Dunelm graphic UIs, extending beyond the website project.

When evaluating their options, Dunelm realized that a micro frontend (MFE) architecture was their best option. It could help them achieve most of the benefits they desired, although the last three (pertaining to the website user experience) would not be achieved directly with an MFE architecture.

But what are micro frontends? Micro frontends are a distributed systems approach for the user interface. They leverage the same principles of microservices such as independent deployment, reduced errors blast radius, reduced cognitive load for teams, and accelerate the evolutionary nature of a system.

After careful evaluation, Dunelm decided to implement an MFE architecture, which would enable them to split the frontend into independently testable and deployable sections. An MFE architecture enabled Dunelm to resolve their two main issues of assigning ownership and increasing lead times.

MFE architecture reduces external dependencies among separate sections of the frontend and enables teams to take full ownership of individual website sections. This empowers developers to have a deep knowledge of the code, and grows confidence in changes, fewer tests, and faster feedback loops. With teams working on smaller sections, this provides the added benefit of reducing the cognitive complexity required to make changes—improving the developer experience.

Dunelm’s approach: Designing a target architecture and migration strategy

Figure 1 – Micro frontend fragments and their arrangement

In planning the website’s structure, Dunelm divided it into vertical fragments based on page groups, allowing for incremental migration and aligning well with their team setup. For the horizontal fragments, they decided to simplify with just three:

1. Consistent header

2. Consistent footer

3. Flexible page group fragment

The approach involves a poly-repo for each vertical fragment, granting teams more control over their website areas of ownership.

The decision to implement page group fragments is rooted in the synergy it creates with Dunelm’s organizational structure. The engineering teams at Dunelm are structured to take ownership of entire verticals within specific website areas. For example, a dedicated team oversees the basket and its related services, while another focuses on order data and the checkout pages and services. This organizational alignment ensures efficient management and ownership of distinct website functionalities by specialized teams.

A dedicated component library was created to share code effectively between poly-repo micro frontends, aiming for consistent user interfaces across projects. Dunelm enforces a principle called ‘Share nothing by default’, adding components to the shared library only as necessary. This helps balance efficiency with encapsulation.

Figure 2 – High level architecture diagram of second approach

Delving into Dunelm’s high level micro frontend architecture, they have introduced Compute within the content delivery network (CDN). This enables custom code execution to enrich incoming requests.

Each execution Compute retrieves feature-flags from a third-party service, called Launch Darkly, for website experimentation and determines routing to the application shell or the legacy website. The application shell acts as a module federation host, leveraging a dynamic code-sharing pattern. This enables the pulling-in of content from fragments and sharing their common dependencies. This reduces the JavaScript required to load a page, significantly enhancing page performance.

Each fragment operates as a module federation remote, allowing exposure of necessary parts to the application shell. Upon fragment changes, the build process bundles assets and stores them into an S3 bucket, referenced by a remote entry file. Fragments communicate with downstream services, third-parties, and the shared component library as needed.

Figure 3 – Strangler migration pattern

Dunelm adopted an iterative migration strategy using the “strangler migration pattern”. This pattern is well known for transitioning from monolithic to a micro-services architecture. It is also well suited to micro frontends. Dunelm plans to migrate one page-group at a time, gradually reducing the size of the existing monolith while expanding the number of micro frontends until the entire system is on the new architecture.

To enhance stability and better implement governance, Dunelm has strategically formed an enablement team responsible for overseeing key components such as CDN, Compute, and Application shell. This team not only guarantees the smooth functioning of these elements but also proactively shares expertise regarding integration and the development of high-quality solutions within the platform. Additionally, they create tools and guardrails aiming to streamline work complexity and elevate the overall developer experience for the numerous teams who work on www.dunelm.com.

For observability, Dunelm meticulously tracks Real User Monitoring (RUM) data, categorizing and reporting on it based on browser and device types. Synthetic alerts are configured to promptly notify the appropriate team if any metrics fall below acceptable thresholds. Additionally, Dunelm has built internal pre-production tests that measure the performance impact of newly built website features. This ensures that performance remains optimal, as issues are detected before they are deployed to production.

Results

This strategy is effective for Dunelm because they can develop and refactor in a separate application without interrupting other teams or impacting customer purchases. When it is time to rollout a micro frontend, the impact of the release is limited only to that page group—effectively limiting risks.

Dunelm has recently marked a significant milestone by transitioning their product detail pages to their new micro frontend architecture. The first migration saw over 60,000 product detail pages successfully migrated without any down time, leveraging Compute to route traffic to the application shell. Upon the initial deployment of these pages, all the core website vitals Dunelm tracks on mobile devices showed a clear improvement—moving into green for all measurements.

Dunelm have observed significant improvement in the speed of changes and the release of a micro frontend compared to the legacy website. Specifically, the pipeline itself is several times faster and the lead time on website changes is significantly reduced. On average Dunelm already releases twice as often through their new platform compared to their legacy one. This is likely to improve further as more sections of the website are migrated to the new architecture. Some of the improvements reported by Dunelm include:

Increased add to basket rate.
Decreased bounce rate.
Increased revenue per session.
Average runtime for CI/CD pipeline is nearly 3 times faster than the legacy website.
The pipeline is 2 times more reliable, and teams release twice as often with MFE.

Warren Fitzpatrick (a Principal Engineer at Dunelm who is responsible for leading the engineering teams and steering the migration and execution of micro frontends) said,

“Dunelm plans to grow their product catalogue significantly in the coming years. With this new architecture in place we can effectively scale infinitely by routing any page to a brand new micro frontend without impacting other pages or teams. We feel like we’re ready to scale and meet the demands of change, whatever it looks like.”

Paul Kerrison (Director of Engineering and Architecture at Dunelm) said,

“‘Strangle it and chop it up’ may sound like an extreme approach to improving customer experience, accelerating delivery and enabling innovation, but the flexibility we’re unlocking is powering the next chapter of our web platform evolution. The combination of micro-frontends, feature flag management and centralized components put together by a brilliant team of technologists will help ensure Dunelm remains a leader in the homewares sector and adapt to our customers’ changing needs.”

Conclusion

With a micro frontends architecture, Dunelm has found that its teams do not need to worry as much about how their changes affect other teams, thanks to the decoupled nature of projects and releases. This, in turn, reduces roadblocks on innovation and allows teams to release changes more often.