From one webshop to a multi-tenant setup

Since the moment I arrived at Wehkamp, I’ve always worked for the one webshop we had. Over the past years, we migrated from an on-premise to a high-performance multiservice structure through a Pac-Man approach by slowly replacing bits and pieces. After almost finishing this project the next challenge came along:

Is our current setup multi-label, or can we make it so?

There were plans to take over another Dutch brand, Kleertjes.com, and make it land on the same platform with the same codebase we have set up for our main brand. The short answer to this question is yes! Looking at our microsites and services, we could easily extend them with some extra configurations to handle different labels. Although we still had to overcome some extra challenges as not everything from on-premise was already migrated, that gave us all the more reason to finish that up.

From one shop to multi-label

As the initial plan was to migrate Kleertjes, we decided to prove our concept with a newly created brand, Union River, first. We came up with a design plan, made the sites configurable, and set up a new space in AWS where we copied and deployed them.

Both sites are now running in their own space without interfering with each other and working in the same way. A customer visits the site, and the consumer gateway directs the customer to the correct microsite, which then shows the correct page (in this case the homepage).

Our two labels in a simple overview, deployed in their own space

Setting up a multi-label design system

One of the most important things to start with is setting up a workable design system that is easy to set up and use. We decided on generic functionalities and brand-specific styling. In our case, the layout of the site will be the same for all labels, but the brand comes to life by changing elements like the logo, fonts, and especially photography.

Multi-label design system

To make this configurable, we decided to use CSS variables and load the correct CSS theme per website. Now we can easily change the look and feel of elements by simply changing some values.

Different look and feel due to brand-specific styling

Make sites and services configurable

As most of our sites and services were already driven by environment variables (because of development and production), it was pretty straightforward to copy and adjust the existing configurations to the new space. In some cases, we also added extra configurations to the sites and services. For example, these settings:

export default {
  'wehkamp' : {
    brandName: 'Wehkamp',
    showReviews: true,    
  },
  'kleertjes': {
    brandName: 'Kleertjes.com',
    showReviews: true,
  },
  'unionRiver': {
    brandName: 'Union River',
    showReviews: false,
  }
};

Try to think in features, not in labels

One of the lessons here, when making code configurable, is to try to think about features. You don’t want to extend code statements with labels, but you do want to be able to toggle features. For instance, if you want to show reviews for certain labels, Create a new configurable setting instead of extending an if clause.

//  do not use labels
if (label === 'wehkamp' || label === 'kleertjes') { ... }

// use features
if (showReviews) { ... } 

After making the whole setup multi-label, the next question came up. Can we also expand this to maybe 10 or 20 labels? Again, the short answer is yes, but not in this way. Maintaining and deploying to a space per label is not workable and efficient for all the teams involved, and cost-wise, it’s a pretty expensive solution.

Next step: multi-tenancy

What if we could alter the sites and services to dynamically change based on an incoming label? In our current setup, a site is deployed with an environment variable stating which label it is. If we could dynamically change that, then we could also move to a one-space setup.

In the one-space setup, the customer lands on one of our websites, which propagates the correct label via the request headers throughout the stack. We let the domain determine the label instead of a setting, and if we set it up correctly, we could then easily show all our labels within one setup.

Multi-tenancy in a one-space setup

Multiple databases or multi-schema

During the multi-label phase, our first idea was to create a new database per label. Of course, there’s nothing wrong with that approach, but in some cases, it would also be beneficial to look at a multi-schema approach. In all cases, you should use the best solution for your challenge.

A nice feature would be, that a service automatically creates the database or schema for you when it’s requested with a new label. This will save time for all the new labels to come.

Configuring the labels

To maintain our labels, we needed to create a new management site. As now most configurations live in the code, we needed to move that to a service so we could easily and quickly set up new labels.

We created a new CMS (Configuration Management Site) and connected the outcome via a service or a Kafka topic to the sites and services. Based on the header, the requester will get the correct label configuration. We’re aware that this will be a single point of failure, but we have everything in place to make sure that this will not be an issue.

Pros, cons, and the future

We started our journey with one shop, made that multi-label, and the proposed end state will be a multi-tenant shop. How this multi-tenancy will hold up in the future is still a question, as we are still working in small steps towards this end state. For now, the pros outweigh the cons, but who knows where the future might take us?

Pros

• single deployment for a site/service
• lower costs
• easy to add new labels
• all labels have the same features
• one testing pipeline

Cons

• one label goes down, all is down
• all labels have the same layout and may look/feel the same
• passing an incorrect label can corrupt a site and data
• high load on one label can affect the other
• adding a single point of failure (configuration service)

Thank you for taking the time to read this story! If you enjoyed reading this story, clap for me by clicking the 👏🏻 below so other people will see this here on Medium

I work at Wehkamp.nl one of the biggest e-commerce companies of 🇳🇱
We do have a Tech blog; check it out and subscribe if you want to read more stories like this one. Or look at our job offers if you are looking for a great job!