Stuart Kochmer, Principal Architect
When you have multiple brands or a single brand that serves diverse geographic markets and audiences, you may need to vary pricing, offer different catalog choices, change how accounts are modified, or use different shopping carts. Delivering these kinds of customized experiences can have a dramatic impact on both revenue and customer engagement.
While customization improves the digital experience for customers, it can take time for companies to build and deploy custom stores efficiently and cost-effectively.
As experienced cloud engineers, we advise clients against writing expensive separate applications for each branded site. Instead, we leverage the same code for all services and Javascript UIs to leverage efficiencies for multi-brand services and interfaces.
This article explores two technical approaches to providing this type of multi-brand functionality.
One approach to providing services to support multiple brands is using feature flags and configurations to offer minor functionality differences, ignoring the brand concept in the code, which keeps all datastores easily configurable.
In this scenario, we use infrastructure as code (IaC) to deploy the same services and associated compute resources, including storage. However, we point to different configurations for each brand’s datasources, features, and resource capacities. We have applied this strategy successfully with numerous clients, including Backcountry.com and Competitive Cyclist. These sites use identical backend codebases with different configurations to drive the differences you see on each site.
Advantages of this approach
Isolation of brand data
When each brand uses separate datasources, storage, and APIs, it ensures that code or data analytics bugs will not inadvertently expose data from other brands.
Separate compute capacity, regions, & costs by brand
Using IaC, we can provide each brand with its own logical set of compute resources that can quickly scale up or down. Similarly, these compute resources and services can be deployed to appropriate regions. This separation means that a spike in traffic or an outage of one brand’s services will not affect others. In addition, brand resources can be owned by separate cloud accounts to keep costs separated and provide visibility to costs by brand.
For example, a brand may have a US-based ecommerce store and fulfillment center as well as a European and Asian ecommerce store and associated fulfillment centers. Each regional storefront could have right-sized data storage and compute capacity in the regions that are geographically closest to their user base.
Deployments isolated by brand
Each brand having its own compute resources and services allows you to release new code or change compute capacity without impacting other brands.
Disadvantages of this approach
Resource duplication
Because each brand has its own compute resources, you may incur additional costs for licensing, compute, or storage compared to the alternative, where multiple brands share the same resources.
Deployment complexity
While each brand having it’s own compute resources and services offer flexibility, it also adds complexity when deploying changes consistently to each brand. Building pipelines that deploy to multiple brands and IaC may help but requires more effort to develop and maintain than the alternative approach.
Another approach to providing support for multiple brands is to implement services that are brand-aware. This requires knowing which brand each request is associated with and ensuring that brand data is kept segregated appropriately in datastores. This may also result in brand-specific code within these services. A brand-aware strategy requires shared services and associated compute resources, including storage across all brands.
Advantages of this approach
Shared resources
Using the same services and associated compute resources for all brands can reduce licensing costs and the overall cost of compute resources.
Simple deployments
When all brands share services and resources, code deployments and infrastructure changes require less effort to deploy and manage via build pipelines and IaC.
Disadvantages of this approach
Performance risk
If all brands share the same services, it increases the risk of one brand’s high volume of requests degrading the performance of other brands. While you can take steps to mitigate this risk, it takes considerable effort to ensure individual brands do not impact each others’ performance.
Weak data isolation
When brand data resides in the same storage resources, you will need additional code and security to ensure that one brand cannot access another brand’s information.
Code complexity
Services using this approach have to be brand-aware for all logic to ensure data segregation and to provide specific features and business logic appropriate for their needs. There are design patterns that can address this, but it is more complex to architect and implement than the first approach.
Which approach works best for your needs?
We have found that the “same code, different configuration” approach is ideal for two primary use cases. The first is when you support a small number of brands with different capacity needs and/or want to segregate their resource costs. The second is when your security and regulatory requirements mandate data isolation, including restrictions on data living in a shared memory space.
In contrast, the “brand-aware services” approach is appropriate if you need to support tens or hundreds of brands. In this scenario, having a single set of services and compute resources drastically reduces costs and management and deployment complexity.
Benefits beyond services
These approaches can be applied to your services and storage and all layers of your application, including your user interface. For instance, you may provide multi-brand functionality by hosting a single web domain for all brands and use subdomains, subfolders, or brand-specific authentication. Alternatively, you can use the same code, different configuration approach to create separate domains and corresponding front-end deployments per brand.
Global Retail Ecommerce
A global retail apparel brand with fulfillment centers in US, Europe, and Asia is building an ecommerce site and mobile apps to support customers in these three regions. The solution stack includes a React UI, iOS and Android mobile apps, microservices for searching, product details, shopping and checkout services, and a database. Some external integrations differ for each region, like payment gateways and shipping providers.
For this scenario, the same code, different configuration approach is an ideal solution. It allows you to build the UI, app, and service code and then deploy it to each region, with configuration driving the appropriate integrations and features.
Small Business Invoicing Service
A startup is creating a service that helps manage billing and payment services as a SaaS offering for small businesses. They have a React UI, iOS and Android mobile apps, microservices for generating and managing invoices and accepting payment, a database, and storage buckets for invoice PDFs.
This scenario is perfect for the brand-aware services approach. Each business using this service will likely only generate a small amount of load and data, and there will probably be hundreds of individual brands, so sharing resources makes sense.
Our team used this approach with Quickbox Fulfillment, a 3rd party logistics provider. The company has hundreds of individual companies that ship items from their warehouses. While we built services branded by the company, having unique deployments for each company was impractical. Instead, we utilized a brand-aware services strategy that allowed Quickbox to scale its business faster than it scaled IT infrastructure costs.
Summary
Creating successful multi-brand commerce solutions requires innovative strategies that boost efficiencies, reduce costs, and deliver customized experiences. Depending on your company’s unique needs, each approach can help you achieve brand differentiation and keep the long-term cost of ownership low.
Interested in learning more? Schedule a call with our experts.
Comments