History of IKEA.com: Static files and Microfrontends
A few weeks ago, we at Ingka Digital decommissioned IKEA Retail Web (IRW), a monolithic e-commerce system that has been in production for 20 years. IRW has served us very well over the years, but now it was time to say good bye.
As Mats mentions in the post, we have replaced IRW with a Microfrontends architecture. That’s the modularity aspect of the new architecture. The other aspect is how we deliver HTML: we use static files (ca 40 million of them).
IKEA.com is today developed by 50+ central product teams for 48 countries, where 25 countries have some form of feature development in addition to the central deliveries. In 2022, IKEA.com had over three billion sessions, which is around 100 sessions per second (roughly a low G on a guitar).
In this blog post I’ll look back on the most important events and concepts, according to me.
Background
Early 2016, I was one of the first people in a team which mission was to create an intermediate web solution on top of IRW. There was already another big monolithic web platform that was planned to replace IRW, but it struggled, so there were two main reasons why to create an intermediate solution:
- Be able to enhance/improve IRW with additional and improved experiences “right now”
- Be able to support IKEA’s launch in India a few years later with a great mobile web experience (not possible for IRW and the new monolithic web platform could not meet that timeline)
This was forming a great “Think big, start small” approach: we could start small by creating new web sections “on the side” of IRW, and then start to replace parts of the mobile web experience — implementing a strangler fig application approach. And we could think big by having the long-term goal of having a full mobile web experience in India. Even if the focus was mobile web, we chose to support “large tablets in landscape mode” so that the step from mobile web to a responsive web would be a smaller.
The initial goal was to enhance the site with an inspirational content section within 3–4 months.
Static files
The team was a small cross-functional two pizza team with Product, Engineering, and UX people. We needed to create a solution that would:
- have a fast time-to-market
- handle the traffic volumes of the IKEA web visitors, in the magnitude of billion visits per year
- have a great web performance, in all the countries that IKEA is present in
- not “drown” the team in operational work (robustness)
- be as secure as possible from cyber attacks
How could we solve for all the above constraints, with such a small team? The idea of static files came up: if we could upload static files to a robust storage, we would be able to scale globally with minimal operational work and with great web security. And creating HTML in static files is quite easy, enabling a fast time-to-market.
We initiated a great collaboration with the CDN team, both to host our files in three locations (plus fail-overs) and to eventually create a highly effective caching solution (48h TTL + cache purge when files are uploaded).
HTML Modularity with Edge-Side Includes
However, we almost immediately saw a major flaw in the static files approach: a change the common elements of the web pages (i.e. the header navigation) would force us to recreate the entire site — not great. What we lacked was modularity.
From earlier projects, some team members had prior knowledge of Edge-Side Includes (ESI): a web standards proposal from 2001 that allows HTML fragments to be included by other HTML, like this:
<esi:include src=”/path/to/fragment” />If we extracted i.e. the header navigation to its own HTML fragment, we could then reuse it by including it using ESI. Our CDN supported ESI, so this was an easy decision.
We were able to meet the timeline and the initiative got more and more traction and responsibility, but eventually our team grew to 20–25 people and we started to sense problems in our agile morning stand-up. We were effectively 2–3 sub-teams in the larger team and the standups started to become too long and unfocused. We needed to split the team.
We could split the team either into frontend/backend teams (“horizontal”), or to continue with the cross-functional teams approach (“vertical”). There were pros and cons with both approaches, but we could see that the vertical approach would scale better when the number of teams increased. If we split into frontend/backend, it would only be a matter of time until those teams would become bottlenecks.
Microfrontends with Edge-Side Includes
We split the large team into three teams:
- CMS (stream aligned team¹)
- Product presentation (stream aligned team)
- Framework (platform team)
In retrospect, splitting the team was an Inverse Conway Maneuver that caused enough friction to create the Microfrontend architecture IKEA.com has today.
We already had support for modular HTML, but we needed to come up with a frontend architecture that worked both from a local team autonomy and a system-as-a-whole perspective.
Inspired by the original Microservices article, we came up with three architectural goals:
- Great web performance
- Scalable development — enabling Continuous Delivery for the many teams
- Evolvability–being able to change parts of the system without the need for central coordination
(2) and (3) are very similar and follow the Microservices characteristic of Decentralised Governance, allowing the teams to choose (and change) their own tools as long as the system maintains a great web performance.
In short:
- each team is responsible for their delivery
- page teams own their own head/body tags
- no shared frameworks/libraries/css in the browser
- separate content fragments from resource fragments, where the latter contain cache busted links to JS/CSS dependencies
- use namespaces in the HTML to decouple
During this time, I also wrote down a more detailed description of “how” on a personal website.
Dynamic use-cases with JavaScript
In order to be able to have a complete web experience–in turn to eventually support the launch of IKEA.com in India–we needed to support more dynamic use-cases, i.e.:
- Search
- Cart
- Checkout
Since we already had support for static files, we didn’t need to change anything in the web architecture to support SPAs. Even better, these applications could include the header/footer using ESI, improving First Contentful Paint.
By adding JavaScript and APIs to our static HTML markup, we had created our own modular JAMStack.
People, process, tools
While the architectural properties of HTML delivery through static files and Modularity through ESI is the architectural foundation, there are many other important tools and processes in the socio-technical system, including:
- Our Design System SKAPA
- Documentation, on-boarding process, presentations, slack channels
- Upload Service: abstracting file upload and cache purge (we have changed file origin three times, without noticeable impact from the teams)
- Content Security Policy: an AllowList of what client-side requests are allowed
- Self-hosted instance of Polyfill.io: only serve polyfills if they are needed
- Handling redirects as a failure mode: only check for redirects if origin responds with 404
Summary
With a “Think big, start small” approach, a small team managed to create increased customer value within a short period of time, while also creating the foundation for the web architecture that we have today.
Creating (and maintaining) the aspect of cross-functional teams was a major success factor.
Old and trusted technologies can sometimes be used for new problems — lowering the cognitive load.
This was also a great example of working using IKEA’s key values, including Renew & Improve, Togetherness, and Simplicity.
The next blog post in the series will cover why IKEA.com needs to move its HTML delivery mechanism from static files towards server-side rendering using Edge Computing.
Footnotes
- Team Topologies terminology, see https://teamtopologies.com/key-concepts
