Pros and cons of MACH architecture

Today, the e-commerce market is stuck between business innovation and technological innovation.

On the one hand, the hyper-competitive e-commerce market forces businesses to innovate to remain competitive, with innovations like unified commerce, quick-commerce, circular economy, immersive experience. On the other hand, technologies are evolving very quickly, forcing e-merchants have to stay up to date in order to benefit from the advantages of these technologies and to remain attractive when recruiting.

Faced with these inevitable changes, the Micro-service, API-First, Cloud-Native, and Headless principles have been widely developed in recent years. When we combine these principles, their advantages are multiplied, guaranteeing high scalability, expandability, and fast time-to-market.

This architecture, called “MACH”, is commonly used to build e-commerce sites. It allows you to do “composable commerce”, i.e. build your architecture as if you were assembling legos. We assemble ready-to-use Saas bricks or custom bricks when the needs are too specific. It is then easy to replace a brick if it is depreciated or if the business changes, allowing you to benefit from the latest innovations without having to rewrite the entire application.

In this article, we will see what benefits can be drawn from a MACH architecture and what the associated constraints are.

1st benefit: Develop your platform faster thanks to high modularity

This refers to the promises of micro-services compared to a monolithic architecture. When “slicing” the architecture, the different modules are decoupled from each other, and a module can easily be replaced or added without impacting the others. It is also possible to deploy a service without having to redeploy the entire architecture, thus reducing the production release cycles.

Having these bricks fully usable by API makes them interchangeable, so you can easily replace a brick by modifying the API contracts.

And these bricks compositing the modular architecture can be replaced with SaaS cloud solutions, among the best on the market (“best-of-the-breed”), instead of re-implementing them ourselves. Using turnkey solutions reduces the time-to-market to obtain new advanced features, and merchants can automatically benefit from the updates these SaaS offer, while they do not have to maintain the infrastructure anymore. Examples of cloud SaaS are services like Algolia for research, or Contentful for Headless CMS.

And we can replace our bricks with Saas cloud solutions by adopting a “best-of-the-breed” strategy, choosing among the best on the market in their fields, instead of re-implementing them ourselves. Using turnkey solutions further reduces the time-to-market of new advanced features: merchants can automatically benefit from the updates these SaaS offer. Examples of cloud SaaS are services like Algolia for indexation and research, or Contentful as Headless CMS. At the same time, merchants do not have to maintain the infrastructure anymore.

All of this can be done seamlessly on frontend by being headless. When separating the frontend services from the backend services with the business logic, they are decoupled, and it’s thus possible to make the backend services evolve without impacting the frontend too much, once again, by only changing the API contracts.

2nd benefit: Build better customer experiences

Nowadays, e-commerce services are no longer consumed solely via a website. You can buy products and services via mobile apps, chats, in-store, Facebook, or Instagram social media stores, providing an omnichannel experience to your customers. These new trends are confirmed with, for example, a 45% growth in e-commerce on mobile over the last two years.

To support these multiple distribution channels and these new business models, having a headless and API-first architecture is essential. This allows the use, and even the reuse, of different e-commerce services without having to re-implement their behaviors. For example, the same shopping cart or search module can be used on both the mobile version and the web version.

Frontend development teams can then focus on building a deep user experience. Building a strong identity and immersive features that will allow platforms to stand out.

These websites benefit from the advantages of recent frontend technologies like NextJS, combining the dynamic aspect of a Javascript library like ReactJS with the performance and SEO provided by server-side rendering.

3rd benefit: Bring robustness and scalability to its architecture

Finally, a micro-service and cloud-native architecture provides resilience and scalability. Indeed, having micro-services will allow us to scale on demand using only the services that we need most.

If an incident takes place, we will be able to offer a viable experience without the entire site being inaccessible. For example, if the product recommendation service is down, this will not prevent the user from making purchases.

Cloud providers like AWS will also increase this robustness and scalability because we no longer manually administer servers and applications but use managed services. We can even use serverless technologies to have optimal scalability.

And if you directly use cloud Saas or Paas (Vercel, Heroku), even the cloud provider configuration no longer needs to be done, and you automatically benefit from the scalability and SLAs provided by these services. For example, Shopify has provided 99.99% uptime on all these services for the last 90 days at the time of writing this article.

1st constraint: Require technical expertise

Setting up a MACH architecture is far from trivial These architectures are more complex than traditional monolithic architectures. It is important to have a smart modules separation to avoid ending up in “hell of dependencies” , ie, having to modify too many services each time you want to add a new feature, thus slowing down the time-to-market.

On the other hand, avoiding creating a strong coupling between the services will be advisable. This will prevent obtaining the modularity promised by this architecture.

The APIs developed must also be of high quality and efficient. Technical debt on an API can quickly impact all other services that depend on it. A good mastery of API version upgrades is also required in order to allow their evolutions without breaking their uses.

The data is distributed between the services, and care must be taken to secure their access.

2nd constraint: Add organizational complexity

The complexity of the architecture is also found at the organizational level.

The different functional domains being spread over several teams, requires a good synchronization to deploy functionalities when several domains are impacted. Having headless fronts also encourages this separation, so we can end up with many specialized teams instead of full-stack teams. It is important to have an effective governance in place and to align teams around common goals.

The technical architecture being more complex, it is then necessary to have more qualified technical profiles, who understand the challenges of such an architecture and manage to make a high quality implementation of it. This makes recruitment more difficult.

3rd constraint: Incident resolution is more complex

The additional complexity of the technical architecture is also found in error detection and correction. Especially if you don’t own the services causing the errors, these are “black boxes” and it is more difficult to debug them.

In order to fight against this, it is important to set up effective and relevant application monitoring. This monitoring will be built using modern tools such as Datadog or Sentry, allowing Distributed Tracing. And we will have to log into our systems the responses of the services over which we have no control, this will allow us to gain visibility over the behavior of external services.

Conclusion

During this article, we have seen that a MACH architecture, bringing scalability and modularity, also brings technical and organizational constraints. In order to limit the impact of these constraints and successfully implement a MACH architecture, it is important to follow good practices. If you want to discover more, I wrote a second article with 5 tips to successfully implement your MACH architecture.