E-Commerce Scalability: Planning for the Future
Posted by jdavis
February 2nd, 2010
For the majority of my career I’ve worked on and around e-commerce sites, and I’ve seen a broad range of database designs and site architectures. Within that broad range I’ve seen many good and bad practices, and one of the worst is to design an e-commerce site that can’t scale to meet the business’s future needs. These sites tend to be havens for odd bugs and are likely to become maintenance nightmares.
Scalability takes many forms – for example, the ability to easily add new hardware or bandwidth to handle increases in usage – but as it pertains e-commerce, the area that needs the most scalability is the catalog: the product data, the categorization, and the vast amounts of meta-data that typically accompany them. Both the database and the code need to be designed in such a way that a site can launch with a blue one-size-fits-all baseball cap; the following day add a t-shirt with three sizes and six colors; and three weeks later add a mountaineering package that includes a shell of any available size and color, ski pants of any size and color, and a head lamp.
If the site had been designed to handle only the baseball cap, the seller wouldn’t have been able to start selling those t-shirts without major system rework – and every new product type and customization option would require even more. By spending the extra time and effort to design a robust database and site architecture, the seller can effortlessly add new product types and avoid the delay and expense of modifying an existing system.
Product variations are only the tip of the iceberg. If the site will eventually support international ordering, there are postal codes, taxes, and translations/localization to consider. There may be multiple shipping handlers (e.g. UPS, FedEx, USPS) and payment processors (e.g. PayPal, Authorize.Net). The areas of scalability within an e-commerce site area are endless, and the more features a seller would like to scale, the more time they’ll invest on requirements gathering, planning, design, and development. If the seller really is only going to sell t-shirts and use PayPal as their payment processor, then designing a more robust system would be overkill. However, any seller who is already selling a wide variety of products, is planning to expand their product line, or is struggling with the limits of their existing system should seriously consider the extra time and expenditure required to create a scalable system.
// bw + bsl && x + aw – ah / 2 – cw >= bsl )
{ c.style.left = x + aw – ah / 2 – cw; }
else
{ c.style.left = x + ah / 2; }
if (y + ch + ah / 2 > bh + bst && y + ah / 2 – ch >= bst )
{ c.style.top = y + ah / 2 – ch; }
else
{ c.style.top = y + ah / 2; }
c.style.visibility = “visible”;
} } }
function msoCommentHide(com_id)
{
if(msoBrowserCheck())
{
c = document.all(com_id);
if (null != c && null == c.length)
{
c.style.visibility = “hidden”;
c.style.left = -1000;
c.style.top = -1000;
} }
}
function msoBrowserCheck()
{
ms = navigator.appVersion.indexOf(“MSIE”);
vers = navigator.appVersion.substring(ms + 5, ms + 6);
ie4 = (ms > 0) && (parseInt(vers) >= 4);
return ie4;
}
if (msoBrowserCheck())
{
document.styleSheets.dynCom.addRule(“.msocomanchor”,”background: infobackground”);
document.styleSheets.dynCom.addRule(“.msocomoff”,”display: none”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”visibility: hidden”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”position: absolute”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”top: -1000″);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”left: -1000″);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”width: 33%”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”background: infobackground”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”color: infotext”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”border-top: 1pt solid threedlightshadow”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”border-right: 2pt solid threedshadow”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”border-bottom: 2pt solid threedshadow”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”border-left: 1pt solid threedlightshadow”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”padding: 3pt 3pt 3pt 3pt”);
document.styleSheets.dynCom.addRule(“.msocomtxt”,”z-index: 100″);
}
// ]]>
For the majority of my career I’ve worked on and around e-commerce sites, and I’ve seen a broad range of database designs and site architectures. Within that broad range . These sites tend to be havens for odd bugs and are likely to become maintenance nightmares.
Scalability takes many forms – for example, the ability to easily add new hardware or bandwidth to handle increases in usage – but as it pertains e-commerce, the area that needs the most scalability is the catalog: the product data, the categorization, and the vast amounts of meta-data that typically accompany them. Both the database and the code need to be designed in such a way that a site can launch with a blue one-size-fits-all baseball cap; the following day add a t-shirt with three sizes and six colors; and three weeks later add a mountaineering package that includes a shell of any available size and color, ski pants of any size and color, and a head lamp.
If the site had been designed to handle only the baseball cap, the seller wouldn’t have been able to start selling those t-shirts without major system rework – and every new product type and customization option would require even more. By spending the extra time and effort to design a robust database and site architecture, the seller can effortlessly add new product types and avoid the delay and expense of modifying an existing system.
Product variations are only the tip of the iceberg. If the site will eventually support international ordering, there are postal codes, taxes, and translations/localization to consider. There may be multiple shipping handlers (e.g. UPS, FedEx, USPS) and payment processors (e.g. PayPal, Authorize.Net). The areas of scalability within an e-commerce site area are endless, and the more features a seller would like to scale, the more time they’ll invest on requirements gathering, planning, design, and development. If the seller really is only going to sell t-shirts and use PayPal as their payment processor, then designing a more robust system would be overkill. However, any seller who is already selling a wide variety of products, is planning to expand their product line, or is struggling with the limits of their existing system should seriously consider the extra time and expenditure required to create a scalable system.
Tags: Application development, ecommerce, scalability, system architecture