Tech perspective of an eFood Marketplace from REWE

Successful Growth of an eFood Marketplace: The Tech perspective – 3 Questions for Thomas Vidic, System Architect REWE digital

commercetools author image Stephanie Wittmann
Stephanie Wittmann
Head of Communications & Content, commercetools
Published 04 February 2020

“Development thrives on knowing what has happened in the past.”

It’s been five years since REWE digital chose the commercetools eCommerce platform – a successful cooperation for both. In parts I and II of our interview series, we talked to the marketing and eCommerce professionals at REWE digital. In the third and final part we spoke with Thomas Vidic, system architect at REWE digital.

Three Squad Architects work in the tech team at REWE digital. They use the Merchant Center, one of the components in the commercetools toolset, to work with data and processes, including for product information management (PIM). REWE digital has adopted an approach where all e-commerce employees contribute ideas during a monthly meeting. Thomas Vidic then analyzes these ideas and estimates the costs/effort involved. Suggestions are prioritized and filtered during the development of a preliminary business case. At the end of the process, management decides on the actual portfolio. REWE digital generates six times as many ideas than are ultimately implemented.

Tech perspective of an eFood Marketplace from REWE

Why have you chosen a microservice architecture for the development of the Marketplace and the online store? What advantages does this offer? What challenges did you have to overcome?

At the end of 2014/beginning of 2015, when we had to decide which technologies we wanted to use in the future, microservices were being discussed intensively in the IT community. We were particularly impressed with how microservices could be scaled organically, because it was clear to us from the outset that the platform would need to grow significantly to meet our business objectives. However, such organic scaling can only be achieved when activities can be parallelized, i.e. a team can work on a given task without being dependent on other teams. If you want to avoid having dozens of developers working on a single monolithic software product, microservices are an obvious choice.

Another reason behind this decision was that it was difficult to pin down the feature set that would eventually be needed. As we already knew, it is easier to start with smaller services first, and then extend and expand the features, rather than plan for and program a large and feature-rich program right from the start. When we began, we had a number of senior developers with experience in conceptualizing and implementing a complex microservices architecture. We started with two teams, and now have multiple teams for fulfillment plus additional specialized teams for content. We are also supported by a number of colleagues from the eCommerce teams who are involved in our projects in diverse and dedicated ways. Our internal network of colleagues has grown considerably to help us advance both in terms of technology and content. 

What principles do you use to determine the functional scope of the individual microservices? How are the microservices connected to your business logic?

Individual teams have full responsibility for “their” services – from conception and implementation through to the day-to-day operation of those services. We work to a domain-driven principle: Teams are organized by business domain, for example, sub-areas such as product discovery (including detailed product pages), or checkout (shopping cart). Only in exceptional cases do teams or individual developers work on tasks across multiple domains. However, there can be some overlap: For example, both the shopping cart and search teams use product data, so they must organize themselves and collaborate accordingly.

What other technologies do you rely on? How do you ensure that when new technologies are adopted, the architecture remains stable?

We mostly use Java, Scala, node.js and Kotlin. Each of the three sections, eCommerce, fulfillment and content have a list of programming languages that can be used. Each team chooses the programming language which best suits the solution to be implemented, in consultation with the Squad Architects.

The deciding factor for a language is not solely the efficiency gains it may offer. We have noted that teams grouped around technologies are able to collaborate more effectively through shared development. Not every programming language that is currently “hip” is ultimately useful. Adding new languages without a good reason would lead to an uncontrolled explosion of technologies. This would in turn cause problems for documentation, and when recruiting new employees. In the end, it’s a balancing act: Of course, we want to lure good developers with new technologies, but we can’t afford to lose control of the “software zoo”.

In the former articles of this interview series, we had a closer look at REWE digital’s marketplace and eCommerce strategy along with its interplay with the commercetools’ platform.

More about REWE digital paving the way for the digitalisation of the REWE Group can be found on their website.

commercetools author image Stephanie Wittmann
Stephanie Wittmann
Head of Communications & Content, commercetools

Related Blog Posts