Ideas on the architecture of international B2C webshop rollouts between monoliths, microservices, and self-contained systems

Generating new revenues by means of international webshop rollouts is an idea with which many retail enterprises are currently flirting. Due to numerous pitfalls, venturing digitally into foreign markets is, however, anything but child’s play. That is why internationalization requires thorough planning as a fundamental prerequisite for gaining new markets.

The e-commerce sales curve continues to point upwards. According to forecasts by the U.S. market research company eMarketer, global online commerce is set to exceed two trillion U.S. dollars for the first time in 2017. By 2020 this figure could double. Many retailers see internationalization of their online business as a strategy that promises successful participation in this revenue growth.

The Strategy Determines the Requirements

Achieving this growth is, however, a highly complex undertaking that requires a comprehensive internationalization strategy. Retailers must analyze their company’s individual circumstances and, based on this analysis, formulate an individual idea on the shape that the upcoming international expansion might take. An especially important question in this connection is the extent to which the company as a commercial enterprise is prepared to take into account the country specifics of its target markets.

An especially important question is the extent to which the company as a commercial enterprise is prepared to take into account the country specifics of its target markets.

The answer to this question will depend to a large extent on the company’s specific strategic considerations. That is why, much to the chagrin of many retailers, there is no such thing as a universal patent solution to ensure the success of an international B2C shop rollout. Instead, each company must find its own way within a wide range of options.

One such option is, for example, to manage a company along centralist lines across national borders. In this case decisions made at the company’s headquarters must be implemented internationally. Companies managed in this way logically attach importance to being able to develop and maintain new webshops centrally or to sell all products via a single shop.

Other companies set up in the course of their internationalization separate country companies that manage business in target markets themselves and on the basis of their detailed market knowledge are allowed to make (to a very large extent) independently business-critical decisions such as the shape that a webshop is to take. Marketing too with its key elements for business success such as pricing, offer management, and the development of an end-to-end look and feel in all sales channels is frequently left to the country organizations. At companies run along these lines the decision on whether a product that sells outstandingly well in France should be offered for sale in Russia at the same or a different price is mostly taken in the target market and not at the group’s headquarters, which therefore entrusts country companies with a high degree of flexibility and responsibility. They are thereby able to react independently to the competitive situation in their own markets.

The two variants just outlined serve merely as examples of how general corporate strategy can impact on the planning and implementation of webshop internationalization. There are countless other ways to lead a company into new markets. What can be said for sure is that the webshop architecture must match the preferred internationalization strategy and the resulting requirements.

The Classic Monolith

Many retailers initially see a monolithic architecture as the most pragmatic solution when they embark on their internationalization project. In this case a new shop is developed on the basis of the existing shop system. All international shops taken into production in this way are thus part of a closed system. That has one major advantage. As new shops can follow the patterns of existing ones an international B2C shop rollout involves relatively little expense within a monolithic structure and can therefore be undertaken relatively fast and inexpensively.

The monolithic structure goes on to face a considerable challenge once a few country shops have been launched. Although the initial shop forms the basis for new webshops and many of its characteristics can be taken over, retailers that run their business along centralist lines must also adapt their international shops at least minimally to the country specifics of the market in question. Language, script and currency are not all that can distinguish one country from another; payment method preferences can often differ widely. In addition, nearly every country has its own rules on information requirements or taxes.

In a monolith these specifics can lead to additional expenditure. For one, the ways to deal with them are limited at a monolithic company because all shops partly refer back to the same elements and every change or extension must take internal interrelationships into account. In these circumstances, for example, offering every target market its preferred payment methods is just as expensive as compliance with the different legal framework conditions in individual countries. For another, each new shop and every different circumstance makes the monolith larger and more complex with the result that the system becomes increasingly convoluted and more difficult to maintain.

Classic monolith
The complexity of a classic monolith increases with every shop.

Furthermore, from a certain number of shops efficient test coverage is only possible at great expense if the architecture is purely monolithic. Finally, changes resulting from the joint use of functional elements can potentially affect all shops. So the effects of updates of this kind must be tested in all countries even if an update only relates to one shop. The risk of being caught in a test trap is otherwise too serious. Ensuring testability as complexity increases is therefore a key criterion in the choice of architecture. A high degree of automated test coverage can ease this problem, but it too involves considerable effort and expense.

Modularization Within a Monolith

Limiting constantly growing complexity is one of the major challenges faced by retailers that take their internationalization project forward with a classic monolithic architecture. The most promising way to deal with this complexity is to modularize the overall structure by means of smaller, subject-specific components. That does not necessarily require a breakup of the system’s monolithic base. Instead, this approach within a monolithic corporation can help make the testability of the system more efficient. New or changed system components no longer need to be tested in all country shops and an update no longer requires an overview of the entire system.

Modularization improves the project’s flexibility.

Modularization also improves the project’s flexibility. Adjusting components to meet subject-specific requirements enables different developer teams to work on different modules at the same time relatively independently of each other. In this way country-specific specific special cases can be implemented more efficiently, but this flexibility is not limitless. As the monolith continues to be constructed on a common technical base newly developed or revised components can only be deployed jointly. Instead a release of the entire monolith must be coordinated so as to ensure that the modules continue to match one another. So ruling out unwanted interactions within the monolith continues to be a costly and time-consuming administrative task.

Distributed Systems: Microservices and Self-contained Systems

Monolithic structures are not the only way to set up a webshop. Another option is to encapsulate the modules in separate services and create a distributed system of individual components. Systems of this kind can consist of, for instance, microservices or self-contained systems (SCS).

Complex applications within the microservices architecture consist of very finely granular services separate from and independent of each other. On this basis the microservices each shop requires can be selected individually and in detail. This small-scale structure has a disadvantage, however. The administration and maintenance of microservices is difficult because there are usually many of them with numerous interfaces. In contrast to microservices, self-contained systems are larger in scale. Unlike their finely granular counterpart they are designed as independent Web applications that can be used separately and exchanged flexibly on the basis of their own data management, integrated business logic and user interface. If required, they can fall back on microservices as a basis.

Regardless which variant the retailer chooses, the strong encapsulation of individual modules within the distributed system now enables country-specific components to be developed independently and deployed separately. As a consequence this architecture is of special benefit for retailers that would like to offer their country companies as much scope as possible in designing their webshops and run them on local servers in the countries in question. Developer teams that may even be based in the different companies are thereby able to organize themselves and their work more independently. In theory they can even choose different technologies. In addition, testing is more efficient with this architecture because the effects of updates need only to be checked in the shops that make active use of the component.

Central Core in a Distributed System

The ability to provide country companies with a service developed individually for each functionality does not, however, mean that in terms of efficiency it would make sense to do so. Instead, services that are used by all shops can be brought together in central core. In this case country-specific services are outsourced and only loosely coupled to the core. This approach has two advantages. For one, the core services remain clearly arranged, testable and manageable; for another, changes to local services do not pose a threat to the core.

Distributed system
Country-specific services are not part of the core.

But which services can form part of the central component designed for all country shops and which problem areas need to be solved individually for each country? In view of the enormous differences between the internationalization and IT strategies of individual companies there can be no generally valid answer to this question. The motto “Global where necessary, local where required” does, however, in our experience constitute a rough guide.

Global where necessary, local where required.

In order not to maneuver it into a test pitfall the central component should, in keeping with this motto, not contain too many features, especially those that are likely to require frequent updates. Instead it makes sense to integrate the absolutely basic structures in it – the key components of an online shop such as the product catalog in which the range of goods on offer is stored. To these can be added functionalities such as the search function or the basic functions of the shopping cart that as a rule can be standardized internationally without difficulty.

How quickly country specifics need to be taken into consideration is clear from taking a closer look at pricing within the shopping cart. Regional differences such as different shipping costs break the bounds of a standard functionality that is designed to be global in next to no time. That is why the pricing should be designed for ease of expansion to include region-specific components. A new feature would then require only another component to be devised that in principle is available for all countries even though only a few shops might use it. Any changes to this component would then, as described above, only affect the countries that actively use this component. The effort and expense of testing would thus be manageable.

Another way to cut the cost of programming and testing is to create multi-country clusters. They need not necessarily be language-based, such as by grouping all English-language shops on shared servers. Instead similarities in shopping behavior, comparable forms of sales pitch and the resulting compatible component structure patterns can play a role in deciding which countries can make up a cluster. In addition, clusters of this kind can be used to run centrally or from a larger country the shops of smaller markets that lack the infrastructure required to manage shops themselves. In this way responsibility for looking after shops can be varied almost infinitely between local and central teams.

Conclusion: Architecture is a Determining Success Factor

Choosing an architecture that matches the individual expansion project is one of the central keys to a successful (and, in the long term, affordable) international B2C shop rollout. Retailers are confronted especially by the challenge of reconciling the desire for flexibility in designing individual webshops with the need for efficiency. Setting up a modularized system that both makes deployment more flexible and improves testability is the decisive step toward striking this balance. In this way digital business can be developed directly while at the same time being sufficiently flexibly positioned to make use of future business opportunities fast with the existing architecture.

Image source: Fotolia / Rawpixel.com