A Digital Ecommerce Transformation – Cloud PDP – Part XX

Part XX of a multipart series, goto the beginning with Part I.

The next phase of our move to the cloud in 2012 was to build the Cloud Product Detail Page (PDP). The detail pages are where you land when you select a product from a list or advertisement. It generally has the price, product description, reviews, questions and the all important Add to Cart button.

Cloud Home Page was the first foray into moving TWLER.com to the cloud, but we needed to move more parts of the site to the cloud to reach the scale we were looking for during Holiday. To achieve the goals of our architecture, we were attempting to move the 90+% of site traffic that is people landing on the home page, searching for products and viewing product details. In an eCommerce site, the majority of traffic is simply looking at products and learning about them, only a small portion of traffic makes it to the checkout process.

The Home Page was a fairly straightforward task since we were redesigning the whole page as we rebuilt it. The PDP was much more difficult. First, there were eleven PDPs which all spawned from a single PDP five or ten years ago. Second, the content in the content management system contained custom HTML embedded within the content making it extremely difficult to reuse the existing content. But with 500,000 items in the content system, it wasn’t possible to rework all the content while building out the new PDPs. Besides, the way we were building out the system, the business wanted the ability to fall back on the original PDPs in case the new ones failed. We hadn’t yet gained the trust of the business teams in our first year of rebuilding TWLER.com.

We decided an engineering solution was the only likely way to solve this problem of bridging the old content to the new system. We set some enterprising engineers on the problem; we simply tasked them with figuring out a way to make the existing content work with the new page templates.

We then set out to determine how many new PDP templates we could accomplish by Holiday of 2012. We decided to simply tackle the two highest trafficked PDP templates, computers and TVs. These two PDPs accounted for well over 50% of the traffic to the site. The schedule for the remaining PDP templates went until Holiday 2013.

But there was nothing easy about this task, we struggled with the business to define the new look of the PDPs, we needed to build a framework that allowed most of the PDP to be cached at the Content Delivery Network (CDN) so we could achieve 80-90% page offload to the CDN. We needed to push all that content out of the datacenter for the first time, and have it cached in the cloud. We needed to do this across multiple cloud availability zones. And we needed to meet our page construction SLAs of less than two seconds.

At the time, there were no other retailers pushing into clouds that we knew of, so we were designing the architecture as we went, working with the problems as they came. We tackled content replication via NoSQL databases in a hub and spoke model, only pushing the item data to the cloud and not allowing updates to that content. We built a massive service aggregation forward cache using Memcached that we used to cache the majority of service calls. Netflix Hystrix came out right at this time and we quickly switched from the homegrown version we had been making to the Netflix distribute service management framework. We had to add dynamic page construction to allow for a small amount of personalization. The problems of running a PDP out of a cloud were numerous and difficult.

The overarching Architecture principal throughout this whole effort was to serve all browse traffic completely out of the cloud. That meant getting all product information, pricing, promotions and inventory to the cloud. For this year, we settled on drawing inventory from the datacenter and only calculating promotions when people entered the checkout process. These required business compromises such as language in the cart that said “promotions will be applied at checkout.” But without these compromises, there was simply too much work to get done.

We somehow managed to spin up all the teams necessary to make the new PDP a reality, and get the work done. We relied on great engineers solving problems on their own rather than waiting for high level decisions or guidance. They didn’t fail us. In fact, they worked out a way to strip out all the HTML tags from the content system on the fly so that the existing content would work for both the new and old PDPs simultaneously.

Chalk another win up for great engineering!

We were now ready to enter Holiday 2012 with two major pieces of cloud browsing in place, Cloud Home Page and Cloud PDP.

Goto Part XXI