Monolith vs. Microservices: Which is Best for the Modern E-Commerce Business?

monolith-vs-microservices
Summary
  • E-commerce monoliths are simple and streamlined, but they can impede agility and limit the ability to combine services to enhance e-commerce or build new experiences.

  • Microservices bring scalability, flexibility, and independent component development, but also introduce complexity and challenges in managing distributed systems.

  • Retailers need to weigh the pros and cons of different e-commerce platforms to find the right solution to suit their specific business needs.

  • fabric Commerce Platform is a complete platform with core commerce capabilities, giving you flexibility to choose individual components or the entire suite to integrate seamlessly with your existing tech stack.

In system design, a monolithic architecture refers to a design where all components and functionalities of a system are tightly integrated. In e-commerce, monolithic designs lead to unified and self-contained systems that handle various aspects of an online store, including catalog management, cart and checkout, payment processing, order management, customer management, and more.

For many e-commerce businesses, a monolith is all they’ll need. For example, Shopify is the best e-commerce platform for SMBs, providing a one-stop shop for companies to build and launch an online business from scratch. Even though users are confined to the limitations and constraints of a single integrated system, its user-friendly interface, extensive range of customizable templates, and robust set of commerce tools has helped millions of businesses establish a strong presence online.

However, while monoliths can be simple and streamlined, they also have their faults. They can impede agility and make it difficult to compose an e-commerce tech stack with services that can help build new experiences for shoppers. Monolithic applications have difficulty keeping pace with fast-moving industries as they can be inelastic and difficult to scale, and deploying new features or updates can be painfully time-consuming and complex.

Are microservices the answer?

monolith-vs-microservices

On the other hand, a microservices-based architecture separates each component of an e-commerce operation, letting retailers adapt and evolve as needed. This also gives companies greater control over the customer experience by allowing them to finely tune and customize individual services to meet specific business requirements and optimize performance.

However, a full-scale replatform to APIs and microservices is risky, and the architecture also introduces greater complexity, costs, and challenges in managing distributed systems.

So, if monoliths can weigh you down and put you at risk of falling behind, and fully customizable microservices-based platforms can be risky bets, then which is right for your business?

To find the right solution that fits your specific needs, the answer generally lies somewhere in the middle.

Oftentimes businesses require pre-built and fully-integrated core commerce applications that provide the simplicity and manageability of a monolith, but also the flexibility and composability of microservices. You can pick and choose what you want and how you want to replatform your tech stack over time. A great example of this is the fabric Commerce Platform, which is built with a modular, API-first, cloud native, and headless architecture.

What is an E-Commerce Monolith?

In e-commerce, a monolith refers to software architecture where the entire e-commerce system is tightly integrated into a self-contained codebase that unifies specific e-commerce functions, including the data storage and business logic components for catalog, pricing, promotion, and order management, with presentation and shopper interaction components such as content management and the storefront. For example, Shopify, Magento, and Salesforce Commerce Cloud, are all-in-one platforms that allow businesses to build and launch their e-commerce businesses.

All components and features are interconnected and deployed together as a cohesive unit. This approach simplifies development and deployment but may result in challenges related to scalability, flexibility, and maintainability as the system grows in complexity.

The Amazon Prime Video case study

prime-video-case-study

Recently, monoliths have been thrust back into the spotlight, thanks to a Prime Video case study that was published in March 2023. It detailed how Prime Video’s audio/video monitoring service moved from a distributed microservices architecture to a monolithic application, which helped achieve higher scale, resilience, and lower costs.

However, it’s important to point out that individual use cases are not one-size-fits-all solutions that can be applied across the board. With Prime Video, their service for monitoring live streaming quality issues consisted of three major functions:

  • Media conversion;
  • Defect detection; and
  • Orchestration to control the flow in the service.

Because the high-level architecture essentially remained the same, they were able to pack all of the components of the system into a single process (and reuse a lot of the same code).

This specific use case is very different from an enterprise-level e-commerce business. The rigid nature of monolithic commerce platforms often results in insufficient functionality, which makes it difficult for merchants to achieve higher scale, resilience, and lower costs. Instead, a move from a monolith to a service-oriented architecture can unlock the ability to innovate and iterate, at speed and at scale. As operations become more complex, organizations gain the agility to adapt to market changes, introduce new features, and integrate with external systems.

Put simply, microservices aren’t for everyone, but neither are monoliths. However, taking proactive measures to build for the future can help prevent potential issues in the long run. As Amazon’s CTO Werner Vogels wrote:

“I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies. Event-driven architectures (EDA) and microservices are a good match for that. ” 

traditional-ecommerce-monolith

Illustration: A traditional monolithic architecture for e-commerce. Each element is a component within a single monolithic platform. Modifying one affects the rest, as each element shares a unified codebase. Attempts to introduce new elements or expand into new sales channels can result in significant development time and costs, potentially necessitating an entirely different platform.

Downsides of Monolithic Architecture in E-Commerce

Monoliths have been described as applications that “grew over time, became unmanageable and difficult to understand, and has low cohesion and high coupling.” As your business grows, the potential downsides need to be weighed against your needs to determine if a monolithic platform is right for your business.

Keeping up with innovation

The main challenge of e-commerce monoliths lies in the inability of monolithic architecture to keep pace with industry innovation. While monolithic architectures may provide stability and simplicity in terms of maintenance, they often lack the agility, scalability, and rapid innovation potential offered by distributed environments.

The reluctance to transition away from a monolithic architecture can hinder a business’s ability to adapt, explore new market trends, open new revenue opportunities, and respond to customer demands quickly. According to McKinsey:

“Traditional retail architecture typically relies on monolithic and aging applications that dramatically hinder agility and upgrades while resulting in higher overall costs. Moving to a modular, microservice-based architecture can enable organizations to achieve greater flexibility and scalability.”

mckinsey-architecture-operating-model

Lack of elasticity

While there may be modern monoliths that can scale just fine, most of the commerce monoliths available today are built on pre-cloud architecture and scale linearly with hardware. For example, traditional e-commerce monoliths like IBM Websphere and Oracle ATG are known for their reliance on pre-cloud architectures and their limited scalability beyond the capabilities of hardware upgrades. These legacy monolithic platforms often struggle to keep up with the demands of modern e-commerce.

Because monolithic architecture can be inelastic and difficult to scale, the infrastructure supporting monolithic architecture is typically designed to handle regular day-to-day operations (barring any bugs in the code). Issues can arise during peak volume, such as promotions and e-commerce holiday sales seasons throughout the year.

In fact, according to the National Retail Federation, holiday sales can account for 19% of total retail sales. However, these periods of heavy traffic can overburden a monolith with a lack of elasticity, causing delays, bounces, and server crashes that contribute to a significant loss of revenue.

monolith-revenue-loss

Illustration: A simplified overview of how retailers suffer revenue loss when an inelastic monolithic system struggles during peak volume.

Changing or updating functionality

With monolithic architecture, the process of implementing and deploying new features or updates can be time-consuming and complex. Components within a monolith are tightly coupled, making it difficult to modify or update specific functionalities without affecting the entire system.

Due to the “black box” nature of a monolith, changing or updating any commerce functionality can be challenging and require a major investment of time and resources. If a company’s internal IT team isn’t up to the task, it may require the assistance of professional services for even the simplest tasks. There’s also maintenance and debugging, which can be difficult to manage as well.

Furthermore, modifying the entire codebase requires extensive testing and coordination across development teams. This slower time-to-market can hinder a business’s ability to respond quickly to market trends, customer demands, or competitive challenges, potentially leading to missed opportunities.

Finally, if a critical issue arises within the monolithic architecture, it can impact the entire system, potentially resulting in downtime and loss of revenue. A dedicated risk item for a monolithic architecture is the potential for system failures where a single component failure can lead to the entire system becoming inaccessible or unresponsive, resulting in a complete system failure.

What is Microservices Architecture in E-Commerce?

microservices-architecture-ecommerce

In comparison to a monolith, a microservices-based architecture uses independent e-commerce applications to handle each unique business function. These microservices communicate via e-commerce APIs to support a flexible and scalable e-commerce architecture.

With microservices, there’s no single codebase or database to contend with. Each microservice is its own application with its own database. This lets brands change, modify, and scale each microservice without impacting the overall architecture.

Benefits and Drawbacks of Microservices Architecture

Microservices are smaller and easier to manage, they can use tech stacks that meet their business requirements, deployment times are shorter, developers can ramp up quicker, new components can be deployed without impacting the entire system, and most importantly, if a deployment takes down one microservice, the rest of the system continues to work. “

Decoupled, modular, and self-contained systems can offer many benefits. They enable flexibility, scalability, and agility in building and evolving e-commerce platforms to adapt to changes as they happen.

Microservices also benefit retailers looking to enter other sales channels—including introducing a responsive mobile app—by enabling them to adopt a headless CMS. “Going headless” separates the frontend presentation layer from the backend commerce functions to maintain a consistent customer experience across channels, such as a desktop website, mobile app, and even an in-person POS system.

However, microservices are not a one size fits all solution. They come with increased complexity, distributed system management challenges, and the need for careful service dependency management, requiring additional operational efforts.

If there are a set of services that always contribute to the response, have the exact same scaling and performance requirements, same security vectors, and most importantly, are managed by a single team, it is a worthwhile effort to see if combining them (into a monolith) simplifies your architecture.

Differences Between Monoliths and Microservices

traditional-vs-modern-architecture

Illustration: Traditional monolithic e-commerce vs. microservices e-commerce architecture. With monolithic architecture, everything is contained within a single codebase, so changes made to one element affect the rest. In contrast, microservices are independent and can be added and modified as needed without impacting the rest of the architecture.

Part of determining which solution is right for you depends on your analysis of the pros and cons of monolithic vs. microservices architecture.

Concern Monolithic architecture Microservices architecture
Deployment Single unit deployment, often through a single codebase and release. Individual services can be independently deployed, facilitating continuous deployment and updates.
Complexity High complexity due to tight interdependencies within a single codebase. While microservices don’t reduce the complexity of a system, they do make complexity more visible and manageable.
Infrastructure Requires a unified infrastructure to host the entire application. Requires a more distributed infrastructure to host and manage separate services.
Stability Changes or errors in one module can affect the entire application. Independent services offer better fault tolerance, preventing one service failure from affecting the entire system.
Scalability Scaling the entire application, even if only one module needs scaling. Allows independent scaling of services, providing better resource optimization based on demand for specific functionalities.

Every business is different, and as a result, there is no one-size-fits-all commerce platform architecture that perfectly suits every organization’s unique needs and requirements. When deciding between a monolith and microservices, oftentimes the best solution lies in a combination of both.

In other words, pre-built and fully-integrated core commerce applications can provide the simplicity and manageability of a monolith, while still offering the flexibility and composability of microservices. This approach allows businesses to selectively choose and integrate components within their tech stack, enabling easier replatforming and customization based on specific requirements.

fabric Commerce Platform is Purpose-Built for E-Commerce

fabric Commerce Platform is an API-first platform that’s built with core commerce capabilities. It provides retailers with a microservices-based architecture that’s highly configurable, letting you rapidly deploy and scale a flexible e-commerce solution that suits your needs.

Unlike rigid monolithic platforms, fabric’s microservices-based architecture is completely modular, and uses a set of interconnected components and e-commerce APIs that:

  • Help you introduce new features faster
  • Improve operational efficiency by reducing dependency on other components
  • Lowers the total cost of ownership
  • Provides freedom to pick and choose an e-commerce technology stack that works best for your business needs
  • Supports the flexibility to adjust and develop the customer experience your way
  • Evolve your tech stack over time

If you want to learn more about fabric Commerce Platform, or how it offers businesses the ultimate in speed, flexibility, and scalability, get in touch with us here.


Topics: Commerce
Editorial Team

Digital content editorial team @ fabric.

Learn more about fabric