Designing an International E-Commerce System: Platform Architecture Challenges

The decisions we make about the architecture and internal logic of an IT system have profound consequences. They influence all aspects of the platform’s operation, from maintenance, performance issues, and the implementation of business requirements to the end-user experience. It is easier to make architectural choices when we already have a great deal of experience in implementing such systems.

In this article, we want to share some of the best practices in creating IT systems on an international scale.

Out-of-the-Box Platform or Custom Solution?

This question is typically asked when we first start designing an IT system. The answer depends primarily on your business model. To a lesser extent, it also depends on the scale and the number of countries involved.

In a nutshell, an out-of-the-box solution is a good choice when:

• You run a standard business without any unique processes.
• You operate in the B2C sector. This lacks the more complicated ordering processes of the B2B model, which typically include complex order placement systems, multilateral orders, price negotiations, individual terms for specific customers or partners, deferred or credited payments, and many other industry-specific mechanisms.
• Your team has little experience with creating similar projects; experience is needed to correctly develop such a system from scratch.

An out-of-the-box platform has numerous advantages, including:

• Simplified, less complex analysis: You already have a solid foundation, which means you don’t have to create the entire system from scratch. You only need to focus on making the platform suit your needs.
• Quicker deployment of the initial version.
• Lower risk: An out-of-the-box solution covers all the basic requirements, which makes it a good starting point for further development.

Unfortunately, there are also some disadvantages with this option. The biggest one is that a standardized platform makes it harder to stand out on the market. Apart from that, each ready-made solution applies its own philosophy and internal logic—adjusting it to your needs and processes may be expensive.

In such cases, it could be simply too time-consuming to modify or add new features to a ready-made solution. Building a platform from scratch and tailoring it to the needs of your company is a better choice in this case.

There are also other long-term consequences of choosing a ready-made platform when we have unique business requirements. Due to the amount of custom code, upgrading the system to a newer version is usually a major technological challenge. In many cases, the direction of platform development adopted by its creators does not correspond with the specific requirements of our custom implementation.

Single-Instance or Multi-Instance?

Another question we should ask when designing such a system concerns the number of instances.

A multi-instance solution provides a number of important benefits for an international system. It allows us to install the platform for each country (or country group) in a separate hosting subsystem or even in separate locations. As a result, we get:

• A safer model for deploying new application versions. A new application version can be launched in a single country and only propagated to other countries when we are sure it is stable.
• The possibility to introduce separate maintenance breaks for different countries based on the local time.
• A lower risk of loss in the event of a breakdown. The breakdown will only affect the countries which are running on that instance.
• System deployments that are closer to each market, resulting in better performance. 
• Compliance with local personal data processing requirements.

A single-instance system makes it possible to optimize infrastructure and administration costs. We can also divide the logic internally in such a way that a given part—for one country or a group of countries—can be easily extracted when needed. This allows us to flexibly adapt to unexpected changes, even geopolitical ones.

If you decide on a single-instance model, consider what its logical division should look like. This will allow you to extract some parts when needed, such as those related to a selected country or a group of countries. As a result, you will be able to easily adjust to unexpected market changes.

Core and Country-Specific Functions

When creating an international system, it is a good practice to divide the system features into:

• Core features, which are universal and common to all countries.
• Country-specific features, which depend on the nature of a given market.
• Core features’ support processes, which are identical for all countries. These include:
  • Browsing the product catalogue. (The visibility of products is decided at the database level, but the browsing mechanism remains the same throughout the system.)
  • Path to purchase and basket.
  • General marketing mechanisms.
  • Upsell and cross-sell mechanisms.
  • CMS.

Such functions constitute the system core, which is common for all markets.

In turn, the following can differ:

• Languages (Different languages have different word lengths and sometimes even different reading directions.)
• Currencies
• Legal requirements
• Information obligations
• Payment methods
• Delivery methods
• Logistics solutions
• ERP systems

These features should be developed as optional: they can be enabled or disabled depending on the country.

How to Distinguish Between Core and Country-Specific Features

At the design stage, we often do not have complete knowledge about users, purchasing process, and specific countries’ contexts. Thus, we cannot determine which functions should constitute part of the system’s basic logic and which are specific to individual markets. So, we recommend following this process:

1. An MVP version and its deployment. This version only contains basic, business-necessary features. At this stage, we are often unable to separate core functions from country-specific functions. For the initial deployment, we’d typically pick a country that is not critical to our business’ success. 
   After the deployment, there comes the stabilization phase — a period when we monitor the system and are very ready to respond to emerging problems or needs. For about two months, we should gather feedback from real users; this will help us verify our assumptions and introduce some initial optimizations.
2. In-depth analysis and extraction of country-specific features. A single-country system is the starting point for discussion with the company’s online sales leaders in other countries. By referring to the existing system, product owners can more easily indicate which features of the existing platform will be used as they currently are, which features will need minor adjustments, and which should be country-specific features. We should also pay attention to the requirements we get from multiple markets — when requirements are repeated many times, they may end up as new core features.
3. Feature development and new deployments in other countries. Based on the in-depth analysis performed, we can start creating the final version of the system and plan its rollout in all countries. We can also use an agile or iterative model, where an in-depth analysis precedes any implementation.

This process ensures system consistency. Subsequent deployments make the most of the existing and emerging core functions, whose libraries grow with each rollout. At the same time, we avoid extending the system with features that will only be used in one country.

Extracting Microservices

We should extract some modules into separate applications or microservices in the same manner as we extract core features from country-specific ones. This approach has the following benefits:

• The simplification of the e-commerce system itself.
• The natural avoidance of “spaghetti”-type dependencies in the e-commerce system.
• Usage of the best possible technologies for a given solution. (An e-commerce system, especially one built on a platform, does not have this flexibility.)
• The possibility to use dedicated services in other IT systems, not just the e-commerce system.

For example, suppose you are a B2B company with a large product base. If each business client is provided with an individual price, you may encounter problems related to price calculations visible to the users in the system. Calculations take up too much space if persisted as static values. But when an e-commerce system loads prices directly from an ERP, the process takes too long. 

In such situations, you can extract a module for price calculations into a separate microservice. Such an application can then be used simultaneously by an e-commerce system, a CRM system, and any applications that support offerings. This will effectively take some load off the ERP system. It will also isolate the front-end applications from the unavailability of the ERP system.

Rollouts as Separate Projects

We often underestimate the scale of a rollout to another country. We tend to think that an already-developed system is easy to deploy in a new market. In practice, however, it proves otherwise: deploying a system in a new country is always a separate project. It requires a team that will work together and includes multiple tasks which are managerial or procedural rather than strictly technological. These include:

• The analysis of country-specific functions and the collection of business requirements
• The analysis of requirements for new integration interfaces—or changes to existing ones.
• The development of new functions and integration interfaces, or, less frequently, the transfer of core features to country-specific features.
• The preparation of translations and system localization.
• Product matching.
• Integration tests.
• Performance tests.
• User training.

This is by no means a complete list of tasks. Rather, we wanted to indicate how complex and comprehensive the process can become. This is why rollouts should not be limited to technological issues.

International E-Commerce: Challenge on a Huge Scale

Creating an international e-commerce system (i.e. a system that can be expanded into new markets in the future) is a completely different challenge from building a platform that will only operate in a single country. In such cases, we need to consider numerous issues related to the architecture and UX. We also need to choose between an out-of-the-box system and a tailor-made solution.

If you’re considering an out-of-the-box platform, make sure it provides flexibility in creating country-specific features. This is because such platforms frequently offer limited support for international expansion and only cover a fraction of international e-commerce systems’ requirements.

Any e-commerce solution is a challenging decision and a choice that you’ll have to live with for many years. Make sure your chosen solution comprehensively supports international business expansion.