Microservices-based architecture in e-commerce

Microservices-based architecture is a software architecture pattern that provides a way to build your software system as a collection of small services that each have a specific responsibility. The idea is to split your functionality into discrete, independently deployable units such that each unit can be scaled independently and developed by different teams. Microservices-based architecture exists in contrast to a monolithic architecture, where your software system is implemented and deployed as a single unit.

In a microservices-based architecture, each microservice usually has its own database (though there are specific circumstances that may cause one or more microservices to share a single database). Microservices define their own Application Programming Interfaces (APIs), and communicate with one another via APIs or asynchronous messaging. Communication via APIs requires a common language such as SOAP, REST, or gRPC. Communication via asynchronous messaging requires a message queue or log such as Apache Kafka or RabbitMQ.

In this article, you'll learn more about what microservices-based architecture is and how it can help you build scalable e-commerce systems.

Benefits of a microservices-based architecture for e-commerceAnchor

Microservices-based architecture offers several benefits to software development teams building e-commerce systems. Let’s take a look at a few.

Simultaneous work across development teamsAnchor

An e-commerce software system typically consists of several components including inventory, shopping cart, checkout, payment gateway, blog, and so on. Multiple software development teams may need to contribute simultaneously to the development of these components. In a monolithic architecture, there is a higher likelihood of tight coupling among components, which makes it more difficult for multiple software development teams to make concurrent changes to the system. In a microservices-based architecture, the components that make up an e-commerce system can be implemented as separate microservices. Each software development team can work on each service at the same time with little to no impact on other services.

Improved fault isolationAnchor

Microservices also offer improved fault isolation. Since microservices-based architecture enables you to implement subsets of e-commerce functionality as separate microservices, a fault in one microservice is less likely to cause the entire e-commerce system to stop functioning. For example, a fault in your blog service will not affect other aspects of your system, such as inventory or checkout.

Improved scalabilityAnchor

A microservices-based architecture enables you to scale individual parts of your system based on the unique requirements of each part without needing to allocate more resources to the entire system. Given the varied functionality present in most e-commerce systems, it is possible for each microservice to have different scalability requirements. For example, if you publish an article on your e-commerce blog that becomes popular and leads to a surge in traffic, you will be able to scale the specific service that handles your blog without having to scale your entire system. Generally, if one microservice in your e-commerce system becomes too slow or busy, you can simply add more instances of the specific service depending on how much traffic it's getting.

Independent deployabilityAnchor

Similarly, a properly designed microservices-based architecture enables you to independently deploy changes that occur in one microservice without having to deploy other microservices. Independent deployability allows you to steadily deliver new features or fix problems in a particular service without needing to redeploy your entire e-commerce system or extensively coordinate deployment across multiple software development teams.

Flexibility in technology choicesAnchor

Monolithic architectures are typically implemented with a single technology stack (programming language, database, etc.), regardless of whether the technology stack is the best tool for each part of the system. In contrast, a microservices-based architecture allows you to build each microservice in your e-commerce system with a technology stack that is best-suited for the functionality it provides. You can also change the technology stack used to implement a particular microservice without breaking or affecting other microservices.

Components of a microservices-based architecture for e-commerceAnchor

Imagine that you are building an e-commerce system to display product details, manage inventory, take orders from customers, and publish a blog for e-commerce-related content. The following diagram illustrates a microservices-based architecture for the e-commerce system:

Architecture diagram courtesy of David Adamo.

The architecture consists of a user interface (web and mobile application), routing layer (API gateway, load balancer, service registry, and message broker), several services that provide specific e-commerce functionality, and databases for data storage and retrieval. It also includes a third-party content management API that is used to manage a blog. In the following sections, you'll discover the role that each component plays in this architecture.

User interfaceAnchor

The user interface provides a way for end users (e.g., customers, inventory managers, or external partners) to interact with the system and carry out specific operations (e.g., search for an item, add an item to the shopping cart, or add an item to the inventory).

For e-commerce systems, it is typical to provide a Graphical User Interface (GUI) that is usable on both desktop and mobile devices. You can build these UIs using client-side web development frameworks such as React, Angular, or Vue.js. You can also build them with native Android or iOS development tools to provide an effective way for end users to access your e-commerce services on their mobile devices.

Routing layerAnchor

When users perform tasks via the user interface, the UI sends requests to the routing layer. The routing layer is then responsible for sending requests received from the UI (or from some other microservice) to one or more target microservices. A typical routing layer includes an API gateway, load balancer, service registry, and message broker.

Since each microservice in the e-commerce system provides its own API and there are typically multiple microservices, the web and mobile UIs may need to send multiple requests to different microservices to retrieve inventory and product information. The API gateway reduces the need to make multiple requests to different microservices by serving as a single entry point for requests. It may simply forward requests to the appropriate microservice or fan out a single request to multiple services. It also serves as a layer of indirection that enables you to make changes to the structure or functionality boundaries of your microservices with minimal impact to the functionality of the UI.

You can implement a scalable API gateway with a variety of different technologies including Netty, Node.js, and Nginx.

The API gateway works together with a load balancer to distribute and balance requests among several instances of a microservice to ensure that no single instance is overwhelmed by the requests. In many microservices-based systems, especially those deployed in the cloud, the locations and number of instances of each service changes dynamically. Your API gateway and load balancer need to know the location (IP address and port) of each microservice they communicate with. Each microservice also needs to know the location of other microservices so that it can communicate with them. You can use a service registry to keep track of the information required to locate each microservice in your e-commerce system. Any communication with a microservice requires you to first query the service registry to locate the microservice so that the request can be sent to the appropriate location. This process is typically called service discovery.

Microservices often need to communicate with one another to carry out specific tasks. In some scenarios, one microservice can call another using the APIs provided by the target microservice. However, communication between microservices via the APIs they provide is synchronous—that is, the sender of a request has to wait until it receives a response from the microservice before it can do anything else.

Message brokers offer an alternative to synchronous communication such that a request to a microservice and the subsequent response can occur independently from each other. For example, in your e-commerce system, when a customer completes an order, you could send a request asynchronously via a message broker to update product availability in the inventory service without having the customer wait for completion of the product availability update. Asynchronous communication allows your customers to interact with other parts of your e-commerce system (e.g. browse inventory, complete another order, etc.) while operations occur in the background.

You can implement asynchronous messaging with several different technologies including Apache Kafka or RabbitMQ.

MicroservicesAnchor

Each microservice is responsible for a distinct portion of functionality in the e-commerce system. For example, the Inventory service is responsible for managing product availability; the Shopping Cart service is responsible for tracking each user's shopping cart; the Checkout service is responsible for placing orders based on items in the shopping cart; and the Blog service is responsible for managing content for blog posts. Some other common examples of microservices in an e-commerce system include a Customers service to manage customer information, a Products service to manage product details, a Tax service to determine taxes to be applied to products, and a Payments service to manage payments.

You can implement each microservice with whatever technology stack works best for the required functionality. For example, you could choose to use a third-party tool like Hygraph to manage content in your blog service instead of building a blog from scratch. In fact, Hygraph can help you manage several different forms of content across your e-commerce system such as privacy policies, Frequently Asked Questions (FAQs), product details, and even arbitrary content from remote sources that connect to REST or GraphQL APIs. You can also implement microservices with a variety of server-side web development frameworks such as Flask, Express, and Spring Boot.

DatabasesAnchor

Finally, an e-commerce system needs to store and retrieve data about products, shipment information, payment details, and any other pieces of data necessary to operate an online store. The data required to carry out e-commerce operations is typically stored in one or more databases. Storing disparate forms of data may require a single type of database or different types of databases. For example, the Inventory service may require a document-oriented database like Elasticsearch so that users can efficiently search for specific products, while the Shipping service may require only a traditional relational database like PostgreSQL. If you choose to adopt the database-per-service pattern, then you will be able to use a data store that is optimized for the specific needs of each microservice, even if that means using different types of databases across your e-commerce system.

ConclusionAnchor

In this article, you've learned what microservices-based architecture is and why it is useful for e-commerce systems. When applied carefully, microservices-based architecture will help you manage scale and complexity in your system. It enables you to make technology choices that are best suited for the specific functionalities your system provides.

For your content management needs, Hygraph provides content management APIs that fit seamlessly into your microservices-based architecture to create, enrich, unify, and deliver your e-commerce content across multiple platforms. Learn more about how Hygraph can help you build better digital experiences.