The challenges associated with multi-stores can be many and varied. As soon as a new language, a new currency or a new domain comes into play, you are well advised to thoroughly analyse the features of the shop system used in advance. Fortunately, the architects at Spryker had all possible and impossible challenges in mind and provided us with a range of options.
What is a multistore setup?
The need to develop and operate separate shop instances for different business requirements is a thing of the past. Spryker allows us to operate as many shops as necessary with one code base. Different languages and currencies, customer pools and products are just as configurable as different business logics. Among other things, the following topics can be relevant for your own project:
Design and layout
Currencies and prices
Tax calculation
Languages
Stock levels from different sources
Shipping methods and shipping service providers
Payment methods and payment service providers
Order processing
Formatting of times, numbers and currencies
etc.
Internationalisation is not the same as localisation
Internationalisation refers to the process of creating software in such a way that it can support localisations. It is therefore the step that must happen first and defines how and where individual localisations are provided.
Localisation, on the other hand, adapts the "look and feel" to the user's culture and language. Among other things, this involves translated texts and an adapted visual language as well as a customised layout. The main focus is on compiling the necessary resources and adhering to conventions introduced by internationalisation. In short, the respective resources must be available for each defined "locale".
Translations
The Glossary module is a central component for localising Spryker. This allows administrators in the back office to create general translation texts for new language mutations or modify existing ones. Manual maintenance of the glossary may not be practicable if external translation agencies or a large number of administrators are entrusted with this task. In this case, it is possible to import complete translation catalogues directly in a CSV file format.
A global sales strategy also raises the question of which countries and currencies should be supported. Whether the project needs a separate domain and a separate store for each country or whether different stores are clustered (e.g. for the DACH region), whether it is left to the customer to choose a language or whether a separate store is created for each language is left to the imagination of the project operator - all options are open here.
Products, categories and CMS content
Different stores also require different configurations for products, categories and CMS content. We differentiate between the localisations on the one hand and the availability of the respective entities in the stores on the other.
Thanks to a flexible fallback matrix, however, it is not absolutely necessary to localise each attribute, option or image separately. It is practical to agree on a standard localisation (usually English) and then fill in missing values with the existing texts and images. It is of course also possible to activate a product, category or CMS content only in a specific store and thus only display it for certain customers.
Taxes and prices
Taxes are a complex issue for every online retailer. Especially if the goods are to be sold in other European countries or beyond. It is essential to automate this tax calculation in order to minimise any errors on the one hand and to spare the product managers' nerves on the other.
Spryker distinguishes between tax rates and tax sets. The tax rate is the percentage of the price that the end customer pays as tax for the respective target country. Tax sets are used to summarise these different tax rates in groups, e.g. to differentiate between taxes on product prices and taxes on delivery costs.
Prices and the associated pricing are different for each project and are therefore very difficult to generalise. To make life easier for developers during implementation, Spryker offers us the concept of price types. This makes it possible to create as many product prices as necessary and then play them out based on the respective use case (customer group, target country, store, etc.) and use them for calculations.
Warehouse management
In a multistore setup, the relationship between the individual warehouses and the available stores can be configured as required. It is therefore possible to create a separate warehouse for each store or to use the same warehouse for all instances.
This architecture makes it possible, for example, to link products for the DACH stores to a different warehouse than for the French store or the UK store.
Business logic
If there are different business requirements for different stores, we can utilise the concept of code buckets. Code buckets define sections in the programme code that can be implemented and realised differently depending on the type of call.
For example, a project can have a checkout process that comprises different steps for different target countries. In some scenarios, the normal checkout may only comprise three steps, while in others it may comprise four.
To map this scenario, a mutation of the checkout process is created for the code bucket and then only executed for the respective target country.
Infrastructure
Spryker can be operated "out of the box" with one instance each for the relational database (SQL), the search engine (Elasticsearch) and an in-memory database (Redis). However, depending on the complexity and scope of the project, this setup may reach its limits. Consider, for example, several highly frequented B2C shops or B2B shops with complex business requirements.
The following options are available to us in terms of infrastructure:
Option 1: Share Everything
As already described in the introduction, the relational database, the searchengine and the in-memory database are shared for all stores. As the resources are shared, the costs for the infrastructure are low. This configuration is best suited to B2C projects with low traffic and a small amount of data such as products and prices.
Option 2: One Database, separate the rest
Each store has its own search engine and in-memory database - but the relational database is shared.
This configuration is best suited to B2B projects with high data traffic and large data volumes.
Option 3: Separate Everything
Each store has its own relational database, searchengine and in-memory database. This configuration is best suited to projects with the following requirements:
Completely different business requirements per shop, such as business logic and functions.
Independent maintenance and development processes.
Separate data management for entities such as products, customers and orders.
Our conclusion
Spryker's modular architecture simplifies the path to an internationally operating e-commerce project and significantly reduces the time-to-market. Due to the complexity that this usually entails, it is advisable to think carefully in advance about what the architecture should look like.
With our team of certified Spryker developers, we accompany our customers on this journey and create specialised solutions for every business model.
Do you need an international e-commerce solution?