eCommerce – headless and slicing

It’s almost halfway through the year already! What’s really clear is that the number of cardboard boxes queued up for recycling, and the number of parcel deliveries made across the country has steadily increased with our rise in online shopping. The December just gone saw a staggering 52 million parcels delivered by AusPost – keeping in mind that number doesn’t include courier deliveries, that’s 2 parcels for every Australian in December! Wow! With the growth in eCommerce volumes comes the need to modernise and grow the capability to handle that kind of customer base.

While there’s a non-trivial set of operational issues that exist, we’re going to focus on the enabling technology. Through the early part of this year we’ve been working on the design of a complex migration and API integration design for an eCommerce solution that needs to accommodate global scaling. It’s an interesting case study in how simple it has become to achieve performance, reliability and global scale for a reasonable price.

eCommerce in particular has come a long way with a range of platforms existing that offer rich and powerful API’s that enable deep integration into the commerce workflow.In this article we’ll pick off a specific part of the design to discuss, and work through the decisions that were made as part of replacing an entire eCommerce stack while continuing to operate the existing site.

Going headless with vertical slicing

Vertical slicing. A long and often spoken about approach to dividing up scope into chunks of work that vertically integrate the technology stack. While it gets a lot of airtime, it’s often not used well or at all in practice. We regularly come across horizontally driven scope of works that load up on risk, waiting until the last moment to link each layer of the architecture only to see mismatched assumptions drive defect counts, testing and remediation work load up, and ultimately delaying the achievement of the reason for the change in the first place.

eCommerce solutions are particularly amenable to slicing, and the infrastructure of the web makes them even more so. In this solution we looked at the smallest change that would enable the richest set of touch points as our first step. With a suite of platform changes to be made we placed a strong focus on establishing the integration and releasing the entire solution – albeit doing very little, in as short a period as possible.

With that in mind our first step was to place a reverse proxy in front of the existing site. Working with section.io we designed a split origin model that enabled us to carve off a small but critical part of the experience. Using this model, we are able to use the same domain root across both new and old origin servers, giving us access to the cookies that represent the active session and cart contents.

From here we’ve got enough control to inject a new cart and checkout experience, presenting us the opportunity to refine and improve a key step in the user experience, driving improved conversion through additional service provision or simply a better checkout experience. By landing these two key elements on the new platform and services, we’ve also immediately removed the integration and release risk associated with a platform migration.

The stuffing

Unfortunately – it’s not all roses and gummy bears. While it may seem simple to drop in a reverse proxy and get on with the route based origin selection – always check with your existing platform provider before you jump in. If they aren’t aware of the change, you may find customers shut out of your site as they interpret the incoming request behaviours – specifically the single source IP on all requests, as attempts to credential stuff or perform other nefarious tasks.

As always – an open and ongoing conversation with your platform supplier is part of a good plan!

---