CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
Showing results for 
Search instead for 
Did you mean: 
Navigating the implementation of Microservices-based, API-first, Cloud-native, and Headless (MACH) projects in the world of digital commerce often feels like solving a complex puzzle. In recent years, MACH architecture—particularly the use of microservices—has been touted as a technological savior. Microservice-based architectures are celebrated for their potential to drive scalable, high-performance systems, adept at handling the ever-increasing demands of the digital world. The appeal is undeniable: decomposing complex systems into manageable, individual services promises increased agility, resilience, and scalability.

Challenges of Pure Microservices-Based Architecture

However, like many things in life, it's not as straightforward as it might seem. The discourse around MACH and microservices often omits the less glamorous side of this architectural style. The challenges, costs, and potential pitfalls associated with implementing and maintaining such systems are frequently glossed over. While microservices can undoubtedly be a powerful tool, they also introduce a new set of complexities requiring careful management.

When organizations migrate to MACH architectures, they must anticipate and address a range of operational challenges:

  • Maintainability & Operations: Adopting MACH architecture necessitates considerable changes in operational models. This distributed architecture demands rigorous upkeep of numerous smaller services, as opposed to a single monolithic system. Managing individual services' interdependencies and coordinating their updates become critical to ensure overall system functionality.

  • Cost Implications: While MACH architecture provides scalable solutions, it introduces complexity in cost management. Pricing structures in cloud services and the overhead costs associated with managing numerous services can lead to an increased total cost of ownership.

  • Technical Expertise: Deploying, operating, and optimizing MACH solutions require specific, often advanced, skill sets. Building an in-house team or outsourcing expertise can present significant challenges, not to mention the ongoing need for upskilling and training in this rapidly evolving field.

Why Do Microservices-Based Architectures Require an Advanced Skill Set?

A prime example of the technical challenges associated with building a robust e-commerce platform using a pure microservices-based architecture pertains to non-functional requirements. In systems engineering, non-functional requirements define the constraints and operational capabilities of the system being built. In the e-commerce space, non-functional requirements such as monitorability, performance, and scalability often dictate whether the platform can handle large numbers of concurrent users during peak periods like holiday sales seasons.

One of the most critical non-functional requirements that any e-commerce system needs to fulfill is consistency to maintain an accurate record of transactions. As we process sales orders and take payments through the e-commerce platform, it is absolutely critical to ensure that the system can guarantee transactional consistency in all situations, even during periods of system outage or failure.

Different Ways to Provide Consistency for an E-Commerce Platform

To design a system that provides transactional consistency for critical business capabilities in e-commerce such as cart, order management, and payment, transaction management and coordination is typically used. Transaction coordination can be achieved in multiple ways:

  • Sharing the underlying integrated transaction manager in a relational database system between these capabilities ensures consistency between transactions (traditional approach with monolithic architectures).

  • Including an external transaction manager in the system design to support XA-transactions that span over multiple systems.

  • Or, with a completely distributed architecture, which microservices architecture often is, by implementing a logical model to compensate for local transactions if one of the capabilities fails to do its part. This design pattern with microservices-based architectures is typically referred to as the SAGA-pattern (please see

However, many of these models for transaction management are costly and challenging to implement. Building and maintaining a platform that manages distributed transactions well requires immense skill from developers and operators.

Is There an Easier Way to Implement This?

We might wonder if there's an architectural style that strikes a balance—offering the agility of microservices while maintaining a solid, consistent core that meets the demands of e-commerce use cases. This is possible by leveraging an e-commerce platform that supports extensibility with microservices, allowing us to envision a system where specific capabilities that do not require transactional consistency are hosted as external microservices, and those that do are provided from the core platform.

This hybrid architecture offers the best of both worlds. It benefits from the robust core of the e-commerce platform, which provides key technical services. At the same time, it leverages the flexibility of asynchronous microservices to add the necessary functionalities and create the desired customer experience. The combination of these two paradigms forms a unique architectural style that caters to the dynamic nature of today's e-commerce landscape.

This approach could address many of the challenges associated with a pure microservices-based architecture while still harnessing its benefits, creating scalable, flexible, and robust e-commerce experiences for customers.

The following picture outlines this architectural style where e-commerce cloud platforms and public cloud providers are interconnected, and how some of the capabilities can be implemented as microservices outside of the e-commerce platform.

Illustrative view of capabilities requiring transactional consistency in e-commerce platform


The microservices-based architectural style is here to stay. The question now is which capabilities could and should be implemented with it. Perhaps, this will be the topic for our next blog post.

If you found this exploration into e-commerce architecture insightful, please leave a comment and remember to subscribe for my blog!
0 Kudos
Great summary Vesa!
0 Kudos
Vesa, I do like this article, provides a comprehensive picture for microservices-based architecture.
0 Kudos
Absolutely agree! Choosing the right e-commerce architecture is pivotal for success in today's dynamic market. A well-thought-out architecture ensures scalability and adaptability, which are essential in driving growth. Looking forward to part 2!
0 Kudos
Vesa, Do SAP commerce cloud give flexibility to deploy services independently with its own database usually how microservices architecture works ? Like can I separate out product, user etc. service with its own transactional database and deploy them independently and still communicate with other core services like inventory, chekout etc. ?
Hi Piyush,

Really good question.

SAP Commerce Cloud indeed allows for the deployment of services (either serverless functions or Docker-based services) with their own databases using SAP Kyma runtime. SAP Kyma is a SAP cloud service that can be connected with SAP Commerce Cloud. It is used for extensions typically written by customers or partners for SAP Commerce Cloud to implement capabilities that are unique to customers' business. Learn more about this topic at: [URL]

Microservices hosted on top of SAP Kyma can locate each other through the service catalog and communicate using APIs.

The core of SAP Commerce Cloud has transaction management, and hence it can guarantee consistency for the cart, order, and payment operations where it is absolutely required. SAP Kyma serves to extend these core capabilities. For example, if we want to enhance order processing on the e-commerce site, we can react to events raised by the SAP Commerce Cloud core in order to add logic to the order processing flow using our own microservices developed on the SAP Kyma platform. For example, sending out an order confirmation email when an order has been received.

SAP Commerce Cloud core can meet the most strict requirements for consistency, security, and data integrity, even under high-volume traffic. Cyber Week and Black Friday in 2023 were again proof of that, as our customers were able to increase their website traffic, conversion, and order processing significantly compared to last year.


0 Kudos
Thanks Vesa for detailed explanation. It really helps !

Just curious on statement "The core of SAP Commerce Cloud has transaction management". 

As per this statement core can have only single database to maintain transaction. Is this transactional database management can be horizontally scale ? Means possible to have more than 1 RDBMS for core to sustain huge billions data as vertical scaling is limited at certain point.

I tried to manage 2 database connection and was succeed at certain point but could not found if SAP commerce officially provide and support it ? 

Looking for your opinion.