Our Blog

Multi-store Architecture for Ecommerce

By Steph Skardal
February 29, 2012

Something that never seems to go out of style in ecommerce development is the request for multi-site or multi-store architecture running on a given platform. Usually there is interest in this type of setup to encourage build-out and branding of unique stores that have shared functionality.

A few of Backcountry.com’s stores driven by a multi-store architecture, developed with End Point support.

End Point has developed several multi-store architectures on open source ecommerce platforms, including Backcountry.com (Interchange/Perl), College District (Interchange/Perl), and Fantegrate (Spree/Rails). Here’s an outline of several approaches and the advantages and disadvantages for each method.

Option #1: Copy of Code Base and Database for Every Site

This option requires multiple copies of the ecommerce platform code base, and multiple database instances connected to each code base. The stores could even be installed on different servers. This solution isn’t a true multi-store architecture, but it’s certainly the first stop for a quick and dirty approach to deploy multiple stores.

The advantages to this method are:

• Special template logic doesn’t have to be written per site — the templates would simply follow the ecommerce platform’s template pattern.
• Relative to Option #3 described below, no custom database development is required.
• Custom business logic may be more easily applied to a set of the stores, without affecting the other stores.

The disadvantages to this method are:

• Maintenance of the applications can be time consuming, as changes must be applied to all instances.
• Custom changes must be applied to all multi-store instances.
• Users and administrator accounts are not shared across multiple stores.

Option #2: Single Code Base, Single Database

In this method, there is one copy of the source code that interacts with one database. The single database would be modified to contain a store specific id per product, order, and peripheral tables. The code base would also have to be modified to be able to limit the visible products described here. In this method, the individual store may be identified by the domain or subdomain. With this method, there may also be code customization that allows for custom templates per store.

The advantages to this method are:

• Relative to Option #1, maintenance for one code base is relatively simple.
• User and administrator accounts are shared across multiple stores.
• Super administrators may view and manage data from one backend administrative interface.

The disadvantages to this method are:

• Rights and role management can be complicated.
• Development is required for code and database customization.
• Development is required for coding to handle flexible templating across stores.

A second option in multi-store architecture may use a data model with store specific entries in various tables, described here.

Option #3: Single Code Base, Single Database with Schemas or Views Per Store

In this method, there is one copy of the source code that interacts with a database that has views specific to that store, or a schema specific to that store. In this case, the code base would not necessarily need customization since the data model it accesses should follow the conventions of the ecommerce platform. However, moderate database customization is required in this method. With this method, there may also be code customization that allows for custom templates per store.

The advantages to this method are:

• Relative to Option #1, maintenance for one code base is relatively simple.
• Relative to option #2, code base changes are minimal.
• User accounts may or may not be shared across stores.
• Relative to option #2, there may be a potential performance gain by removing time spent limiting data to the current store instance.

The disadvantage to this method is:

• Customization and development is required for database configuration and management of multi-store database schemas.

A tangential variation on the methods above are two different codebases and functionality attached to one back-end web service and backing database, such as the architecture we implemented for Locate Express. And a similar tangential variation I’ve investigated before is one that might use a Sinatra driven front-end and a Rails backed admin, such as RailsAdmin used in Piggybak.

College District has a collection of stores driven by a multi-store architecture, developed with End Point support.

Conclusion

In most cases for our clients, there is cost-benefit analysis that drives the decision between the three options described above. Option #1 might be an acceptable solution for someone interested in building out two or three stores, but the latter two options would be more suitable for someone interested in spinning up many additional instances quickly with lower long term maintenance costs.

ecommerce interchange rails spree