The E-Commerce space has been on a consistent upwards trend, which has increased even more due to the current global health and isolation crisis. More and more people, including the elderly generation, are getting used to online shopping. Within the last decade, the comfort level and product portfolio of online shops has grown vastly. The amazing shopping experience offered by leading shopping systems like Amazon, Zalando, or eBay is based on years of technical and functional evolution. From a user perspective, you are guided and maybe even enchanted by the efficiency and joy throughout the whole shopping process. This article will give you insight into the functional and technical challenges of three areas that e-commerce engineering departments have to overcome in order to take part in the race among the best online shops out there.
Hello, again!
Imagine returning to your shop of choice, where you previously ordered some time ago. It says “Hello” to you, mentioning your correct name and showing you recommendations and landing pages that match your profile. It feels like you are already logged in. Well not really, because to place your order or see your personal data, you need to reenter your password. I’ll call it the Amazon-like soft login, where you always stay authenticated but not authorized. Every price is calculated individually for you, with your individual campaign code or dynamic pricing state. Maybe you even have an individual price list in your contract or a flat 10% off. That’s an appealing landing experience for you, and you decide to look out for your product. The shopping journey begins.
Soft-Login
Let’s hold on for a moment and look into the technical challenges that have emerged here. The Amazon-like soft login is something that not many people are really aware of or don’t even know that it exists. It is an example of a customer loyalty feature that goes beyond standard-shop systems and requires a deep understanding of the web, yet is easy to build individually. Most shop-systems let session cookies just expire because they have to protect sensitive data, so you are basically unknown when you reenter the shop. The key is to split identification from authorization in different areas, which for most shop systems almost impossible to realize, except by maybe using custom core patches that most likely would not survive a future required security version update.
Individuality
So, okay. Your beloved shop knows always who you are (as long as you don’t manually hit the log out button), then you see products with your personal prices. Ideally, the shown products are selected by an A.I. based recommendation, which is a common standard in most e-commerce systems. But what about the individual prices, how does that work? Imagine your shop sells around 100.000 different articles or more. Each article has its own individual price and a list of scaled prices. Moreover, there could be an individual price for a specific customer per article. By that point, you are dealing with millions of price list values. These values need to reach the shop via some kind of export/import from external systems. How often do you want to update your prices? Hourly, daily, or near real-time? How do you deal with import errors, completion rates and changing data structures, and most importantly: import performance? The answers to these challenges lie in advanced software architecture disciplines. You need to know and deal with resilient integration patterns, their scale-out behavior, and potential limitations that derive from them. In the IT sector, some engineers have heard of circuit-breaker patterns, bulkheads and NoSQL technologies, but few of them gained crucial practical experience implementing and maintaining them in big systems. Individuality in your shop is likely to let your data grow multiplicative, and so too, the challenges your engineers have to face.
The Omnichannel thing
Omnichannel is another area any that ambitious e-commerce systems have to take care of. The overall perspective is pretty simple: make other platforms sell your stuff. In order to do that, they need your data. Products, prices, delivery information, and so on. The start is easy. Almost any platform has sufficient documentation for the beginning. The first difficulties show up when you integrate with a lot of different platforms. Each platform has its own understanding of integration, technics, and data modeling. This can be a mess when it comes to topics like cart & delivery splitting, b2b & b2c differences, varying fulfillment processes, or publishing and transmitting your beloved product ratings. However, these are more or less standard things to overcome. The real deal shows up when you realize that you are running a big e-commerce system with millions of prices, several thousands of products, and consistent updates among a landscape of distributed systems. You have big batch networks or event sourcing pipelines that update your data (products, prices, etc) every second. How does that cooperate with other sales platforms that expect you to send updates at a maximum of one per day? How do you deal with constant out of sync situations without getting banned from the platform? Regarding this, it is a long process to present simple search results at Google Shopping and Amazon to possible customers. This is just another perfect example of the iceberg theory.
