stunning-devils-tower-2021-08-26-22-29-40-utc (1)

Differences Between Monolithic, PBC, And Microservice Approaches in Ecommerce

A software architecture can follow a monolithic, microservice, or Packaged Business Capability (PBC) based approach to support a business such as an online shop. Each of these has its advantages and disadvantages.

The most common technical concepts/approaches are Monolithic Architectures, Microservices, and Packaged Business Capabilities (PBC). You may have noticed many ecommerce platform providers using these terms to advertise their products.

Each approach to ecommerce software architecture has its advantages and disadvantages, depending on your situation and priorities.

Often the people deciding which approach to use can find it difficult to grasp the highly technical terms and definitions.

This leads to confusion and can end with you choosing the wrong solution for your business needs.

To help you make an informed decision, let’s take a look at those three approaches.

Monolithic Architecture

If you are running an enterprise website, and have been using the same platform for several years, the chances are high that it is a Monolith. That is because the other two approaches are relatively new: The term “microservices” was defined in 2012, and PBCs evolved from there.

In the context of software, the first association that comes to mind for the word “monolith” is something large that covers all the functions you need for the business requirement. That would be the best way to describe Monolithic Architecture.

Applications built in this way are designed to handle multiple tasks and manage a whole array of services. The important thing to be aware of is that software produced this way makes its functions available to the user without the intention of enabling them to adapt or enhance the underlying code.

If any customization is even possible, it has to follow limitations set by the software vendor and more often than not use the proprietary mockups to adjust the solution in a very limited fashion.

This means that due to the proprietary nature of the software architecture, even something small as a bug fix will require support from the software vendor.

Architecture as a Dollhouse

To give you a better understanding of how Monolithic Architecture works, let's put it like this.

Think of a classic dollhouse. It's a big, sophisticated toy. You can customize it with various types of furniture, ornaments, and figurines. The dollhouse can be decorated in vintage and antique styles, or you can give it a look of a modern villa.

Want to Talk More About This?

We look forward to meeting with you.

Start a conversation

Related Posts

    However, the size of each room in the dollhouse will remain the same, and you won't be able to add the new rooms no matter what you do. Much like the dollhouse, you can not change the architecture of monolithic ecommerce software, only the contents.

    This can be problematic when you look at it from a software architecture point of view. Especially when you are dealing with hundreds of products. However, there are some positives to this approach. 

    Pros And Cons of Monolithic Architecture

    Pros

    • Easier creation of workflows. Code is in a single place

    • Simple debugging

    • Easy deployment because there are no dependencies. The whole application is contained within one package that has to be copied to the server

    • Low costs when standard solutions are sufficient for your business

    • It's easy to test new UI features. You can simply launch the application and run a testing tool such as Selenium

    • Many monolithic software vendors offer an app marketplace where you can find more specialized extensions from 3rd parties to add to the software

    • You can easily create good user documentation

    • Out-of-the-box functionality from the start allows faster time-to-market

    Cons

    • Complex code base

    • Implemented with a single programming language: some changes can require the use of a different framework or a complete switch to another programming language

    • Very expensive solution when you need to scale your architecture to accommodate complex business scenarios

    • Limited possibilities to change functions

    • Issues with the performance of the website because only one database is used. Of course, it can be optimized, but with limited options

    • One minor bug can put a halt on the whole operation because to fix it, you will need to redeploy

    • The 3rd party extensions might stop working after an update of the core product until the 3rd party has adjusted their extension to the new (often proprietary) code

    • The software vendor often develops the functions and features of the core product according to the feedback of its biggest customers. As long as these customers use a feature, it will not be removed from the software. That can bloat the software for all other customers

    • Monolithic software vendors that use proprietary code instead of open standards are more difficult to swap out, resulting in vendor lock-in

    • High maintenance costs and development issues will occur as your application grows.

    Microservices Architecture

    While Monolithic architecture runs your application as one single unit, Microservices do the complete opposite. 

    The best way to define Microservices would be to quote the Gartner definition:

    “A microservice is a service-oriented application component that is tightly scoped, strongly encapsulated, loosely coupled, independently deployable, and independently scalable.”

    To paraphrase it – Monolithic architecture runs every single part of your ecommerce application from a single piece of code that is maintained by the same team, usually the software vendor. Microservices on the other hand run each component of the application independently of another, and for each component, there is a dedicated team maintaining it.

    For example, your payment gateway, marketing content, and inventory of items are all separate code bases. In other words, instead of having one massive piece of code that is run from a single location, each application has its own code and runs independently of other services.

    All the communication between the services happens through APIs.

    Architecture as a Lego Set

    A microservice architecture is like a structure built from Lego bricks. You can follow all instructions from a blueprint, or you can build it in any way that you see fit. But no matter which way you decide to go, you'll have to start from scratch.

    Let's say that you have a castle Lego set. Each window, door, turret, flag, and drawbridge would be a Microservice, and bricks that connect these parts would be APIs.

    Once you build a solid foundation of the model, you can easily decide if you want taller towers, a different drawbridge, more or fewer windows, etc.

    Pros And Cons of Microservices Architecture

    Pros

    • Easy to understand the code base because every service has its own

    • Flexibility when it comes to the use of different technologies during the development and scaling of services

    • High fault tolerance. In a situation where one of the services stops working, the rest will keep functioning

    • Excellent solution for an agile approach to development as the solution can be built out gradually over time

    • Having separate teams that are experts for their piece of application makes communication with the business analysts, product managers, and product owners a breeze

    • As your application progresses and becomes bigger and more complex over time, it can be split into additional microservices

    Cons

    • Complex and time-consuming deployment

    • Often not profitable for smaller applications

    • Testing of new features can be complicated because each service needs to be started and tested separately

    • You might be dependent on a good implementation service provider with a proven track record to do the adaptations for you

    • Costs are potentially higher in the early stages of production. At later stages, having multiple databases and various transaction management solutions can bring those costs up

    • The microservices vendor typically will not help you with your specific integration.

    PBC (Packaged Business Capabilities)

    PBC is often mentioned in tandem with Composable Commerce. It's a compromise between Monolithic Architectures and Microservices. Gartner describes it as “software components representing a well-defined business capability.”

    The difference between Microservices and Packaged Business Capabilities is very small. Actually, a PBC is composed of small microservices that are packed together to deliver specific functionality that adds value to the business.

    Previously, we mentioned that Monolithic Architectures have everything written in a single piece of code. Microservices, on the other hand, have all the parts of your ecommerce store written as separate services.

    Packaged Business Capabilities create a collection of microservices responsible for one aspect of your ecommerce. This makes PBC less granular than Microservices and operationally faster than Monolithic Architectures.

    Architecture as a Playmobil Set

    Let's describe this with an example – the Playmobil Medieval Castle set. If you aren't familiar with Playmobil, they create modular building sets.

    As you build, you can add or remove wall sections in any way that you see fit, creating the castle from your imagination. However, if you want to add a door, turret, or archery position, you'll have to add a new section. The new sections you add will not be built from scratch (like with Lego) but contain the necessary components.

    In other words, you can build the castle however you want, but the composition of the individual wall parts cannot be changed. You would have to replace the whole wall section to place the features you want in that section.

    PBCs can contain the microservices you need, much like a wall section can contain the doors and windows you need. You can use them to add or remove services as long as they fit in with the rest of the services in the application.

    Pros And Cons of Packaged Business Capabilities 

    Pros

    • All packages are reusable. Something previously written and encapsulated into a model can be applied in later stages of development if necessary

    • Out-of-the-box ecosystems allow engineers to make quick integrations

    • Perfect alignment between developers and stakeholders. Stakeholders know what they want and developers know how to deliver it thanks to well-documented APIs

    • Ability to try new approaches and innovate because business initiatives can be aligned more easily with PBCs

    • Ability to adapt PBCs to your customers' needs without much complexity

    • High flexibility allows you to build a stack that serves a precise business need. No need to create software that “does it all”

    Cons

    • May require a lot of work from the front-end developers to make the UI uniform across all the services

    • Not as adaptable as a microservice approach.

    What Is The Best Approach For Your Business?

    Each of these approaches is legitimate. The approach that suits you best will depend on various parameters of your business – such as size, complexity, and availability of technical resources.

    Monolithic Architecture is a good architecture solution when your business is starting out (and doesn't intend to scale quickly), has limited technical resources, or is relatively foreseeable. In these cases, your application should have a few standard services which are sufficient for the business to operate.

    Microservices deployment works best for large businesses that have enough resources and skilled experts. A lot of manpower and computing resources behind the Microservices' architecture will return the best-in-class performance and flexibility. A pure Microservices approach is best for companies with custom requirements that simply cannot be fully realized with a monolithic architecture or a PBC approach.

    Packaged Business Capabilities are an approach that is best utilized when you are looking for a balance between the best qualities of the above approaches. A PBC approach makes sense if you don’t have custom requirements for specific business functions, or you lack the experience/skills to customize these (for now).

    Ultimately, the final decision is up to you. Each approach has its advantages and disadvantages, and it all depends on your individual business circumstances.

    If you are still unsure which approach is best for you, contact us and discuss your business needs and challenges with our team of experts.

    Bright Global
    • Expertise
    • Work
    • Approach
    • Partners
    Bright IT
    • Expertise Overview
    • Architecture Audits
    • Legacy Liberation
    • Enterprise Platforms
    • B2C Commerce
    • UX/UI Design
    • B2B Commerce
    • Integrations & Middleware
    • AI & Automation
    • Continuous Operations
    • References & Industries
    • HDI Global
    • Swarovski Optik
    • Mischek
    • Dachstein Salzkammergut
    • Salzburg AG
    • Tyrolit
    • Vaillant
    • Our Philosophy
    • Direct-to-Expert
    • Nearshoring 2.0
    • Security & Compliance
    • Partner Overview
    • Storyblok
    • Optimizely
    • Contentful
    • Shopify
    • Medusa
    • commercetools
    • Ecosystem Integrations
    Insights
    Contact
    Bright IT
    Insights
    • Legal Notes
    • Privacy Policy
    • Follow us on LinkedIn
    © 2026

    Partners