Default Cart, Danger Ahead!

Are you working in eCommerce and issuing a default cart? Ask your architects, developers or simply look at the downloaded items which show up on the first page. Do you see anything that has the label of "cart," "basket" or similar object?

If you are issuing a default cart this means that your complete eCommerce cart management infrastructure needs to have a 1:1 relationship with every person who visits your site. On the long-tail side of the house, this means that your end client has to complete the longest and most complex network traversal in order to use your site. This will slow your end client response time. As conversion rates are directly related to response times this will also reduce your revenue.

Setting the lower revenue issue aside, this also exposes your system to a markedly higher probability of failure under high load/sales days. Why? Because when you hand out a shopping cart for every user your cart management system is under a load which is roughly 900% higher than it needs to be. If we take an average cart use of 10% (people adding an element to the cart), which is pretty close to industry averages, you have an over-allocation of cart resources to non-revenue users by nine times when you hand a cart to every user.

OK, you are probably thinking, "What's the harm here?" Performance is a function of available resources and resources are finite in nature. If you start handing out resources, and large amounts of them, to users who are not going to provide your company with revenue, well your non revenue users are going to crowd out your revenue users for finite resources. This will slow the system down and one item will happen for certain, you will have a higher abandonment rate for users in the process of converting due to slow system response times.

At the performance margin this over allocation of resources to the cart system does result in the cart system running out of resources and failing. When integrated with every page as a default element this also causes the entire site to fail. Even where the web servers may have resources available due to a beneficial caching effect from CDN, as soon as your cart management servers ( application, database, etc...) run out of resources then you are effectively dead in the water.

Are you running on Amazon or other commodity cloud provider which charges for every resource hit on CPU, Disk, Memory or Network. Having the default cart then will not only cost you sales but also cost you many times more to run. That is adding insult to injury.

Cloudy, with increased costs

If you run a commodity eCommerce retail business where the cost of switching is low and a comparable good is available elsewhere then you have likely lost a sale. The opportunity cost is high because the user is also likely to visit the winning provider first in the future.

What can you do right now if you are in this boat? As you don't have the benefit of time to change the nature of the application architecture then the best you can do is stage hardware and personnel resources in the event of resource sparse conditions on your eCommerce cart management hosts. Assume failure and pre-can your responses to particular conditions. You can also lighten up the cart storage:

  • Delete all empty carts from cart storage. Have this run every night before backup and make a note to never have an empty cart stored by future editions of your cart management system.
  • Implement a N:X rule. Anything cart more than ~N~ days old without being touched should be purged before Thanksgiving day. Provide your cart owner with an incentive to convert by Wednesday at midnight or lose the cart. Carts more than ~X~ in size should be sent to inside sales for personal calls to the cart owner to convert. If no convert then purge.
  • Trim your session duration. Many sites implement a default to hold resources for as long as 30 minutes. Analyze your page to page times. Pick the 98th percentile value and make that your session duration. You want to accelerate recovery of the resources for paying customers.
  • if your page generation and your cart management servers share the same hosts then decouple them. Isolate your cart management application servers from your page generation application servers. You want each of them to have as large a resource pool as possible. You also want your cart management application servers to be busy managing carts and nothing else.
  • If you have a unique front page, take your cart off of your front page. You would be surprised how many people/agents just visit the front page and abandon based on either response time or just being called away. With system lockdown you may not be able to make this change.
  • Trial run your disaster plan by Tuesday night, including adding servers to the pool and then removing them to check for impact.