Scaling

It gets interesting when e-commerce picks up a bit more and later becomes a vital part of the business model. Downtime and inefficiencies can then cost a lot of money and do a lot of harm to the business. However, many organizational and technical challenges only become apparent when the number of prospective customers and orders grows beyond a critical threshold. Then, all of a sudden, it takes several seconds to generate a page and to deliver all resources. And just when things are going well, the server collapses or the logistics team can no longer keep up with the flood of orders.

What Does Scaling Actually Mean?

The enlargement of the organizational and technical framework is commonly referred to as “scaling”. This is a central goal in almost every e-commerce business. In addition to growing numbers of site visits and orders, it is also important to be able to process larger import and export processes.

Organizationally, companies can take several approaches to master growing demands. Of course, you will need to take on more staff, but obviously twice the number of warehouse staff will not necessarily be able to handle twice as many packages. Then, the underlying processes and constraints need to be optimized. The magic word here is “automation”: wherever process steps do not absolutely require human intervention, it should be avoided. In any case, machines are usually hopelessly superior to us when it comes to working through monotonous jobs.

So just by automating I can forget about efficiency problems? Obviously not. The technology itself may also contribute the appropriate scalability to help us solve the problem. Software is usually developed, tested, and approved on a small scale, but it is never guaranteed that it will cope with a rush of users and buyers. In the past, I have personally experienced dozens of projects where servers have broken down or import processes have gone into endless mode. Swiss shop Digitec’s report of its experience on Black Friday is just one testament to these types of problems still being normal. The system could only be kept going by the heroic efforts of its IT staff. Hats off to this achievement, but it is to be hoped that it was followed by a critical examination of the capabilities of the underlying systems.

How Can I Scale my Company?

You can handle bottlenecks of this type by using two different strategies: vertical and horizontal scaling. vertical scaling means using larger, faster hardware to make sure there is more capacity available in a system. More memory and larger processors simply make it easier to handle more processes in parallel. In this case, the design of the software is irrelevant—you just throw more hardware at the problem. The problem here is that you quickly reach the limit. The possibilities for growth are therefore very limited. You also need to keep in mind that the price increases faster than the performance.

The possibilities with horizontal scaling are significantly better. In this case, the application is spread across multiple servers, each of which handles a part of the workload. If the requirement for resources explodes, I just fire up a battery of new servers and distribute the extra load to them. Each individual server only needs to handle a part of the load, so only needs to be moderately powerful. As a bonus, this strategy gives you significantly improved reliability, because a single failure will not jeopardize the whole system. Of course, horizontal scaling is not without its own challenges. The increase in efficiency with horizontal scaling depends heavily on the software design, and factors related to licensing policies often prevent an economical implementation.

Scaling with Spryker

Spryker was developed with a strong focus on scalability. The system architecture provides for a strict distribution of customer front-ends—the so-called “apps”—as the actual business logic of the Spryker Commerce OS. Apps can then supply all purely informative views, such as landing pages, category pages, product-detail pages, or even branches, in a completely self-sufficient manner. These account for at least 90–95% of normal shop traffic. The web servers, session and content storage (such as Redis) and the search engines (such as Elasticsearch or FACT-Finder) used for this are based on technologies tried and tested in various high-performance environments and work like a dream in parallel. Quite simply, there is not a single element in the app that would slow the system down. The resulting front-end speed is quite impressive.

Now if you need business logic, the response speeds should not exceed a few hundred milliseconds, even with heavy traffic. Customers are showing an interest in your product, so you should not be putting obstacles in their way. Experience has shown that the database is the limiting element in scaling. Compartmentalization from the front-end significantly reduces the load on the database, however, so that the remaining access can be dealt with in a quick and efficient manner. The rest is provided by the modern structure and corresponding indices. In our load-test scenario, we simulated 2400 shopping-cart accesses on a single server within one minute without the access times exceeding 200ms. That is quite an achievement.

Of course, the Spryker Commerce OS can also be horizontally scaled. Heavy checkout traffic on Black Friday? Do we start up a new back-end instance? A lot of large imports? A new instance of the Spryker Commerce OS works exclusively on the import. The fact that, in addition to the technical possibilities, our order-management capabilities also help master organizational challenges is the proverbial icing on the cake.

So bring on Black Friday! The fact that our customers such as Tom Tailor & Co can process 250% more orders in a weekend is no reason for the project teams to break out in a sweat—it is a cause for rejoicing. The next big event is just around the corner.