Microservices, Composable, and Monolithic Architectures
What is a microservice and how does it differ from monolithic and composable architectures?
A microservice is a discrete, autonomous service responsible for a specific business function, allowing independent development, deployment, and scaling. In contrast, a monolithic architecture tightly couples all processes and capabilities, making updates and scaling more complex. Composable architecture combines microservices and best-fit tools connected via APIs, enabling organizations to mix and match solutions for different business needs. Note: Microservices can add complexity and are best adopted when they deliver a needed business outcome. Source.
When should a company consider adopting a microservices-based architecture?
Companies should consider microservices when they need their solution to evolve rapidly, require high availability, need to isolate data for compliance, or want to enable autonomous teams. Microservices are particularly useful for organizations facing challenges with monolithic systems that hinder agility and innovation. Note: Microservices introduce additional complexity and are not always the best fit for simple applications. Source.
How does composable architecture relate to microservices?
Composable architecture is a strategy for building a tech stack using best-fit tools and connecting them via APIs. Microservices are often a key component of composable architectures, but composability may also include vendor solutions, homegrown services, and even some monolithic applications. The goal is to enable flexibility, scalability, and the ability to swap tools as business needs change. Note: Not all composable architectures are fully microservices-based; most are a mix. Source.
Hygraph & Microservices in Composable Architectures
How does Hygraph support microservices and composable architectures?
Hygraph is a certified MACH Alliance vendor and provides a content management platform with native GraphQL APIs, making it easy to integrate with other tools in a composable stack. Its Content Federation feature helps orchestrate data from multiple sources, and its microservice structure allows businesses to use Hygraph for various purposes, such as unifying commerce data or acting as a PIM. Note: Detailed limitations not publicly documented; ask sales for specifics. Source.
Can you provide an example of Hygraph in a composable, microservices-based architecture?
Dr. Oetker Group used Hygraph as part of a composable architecture to manage digital experiences across 40 markets. Their stack included Hygraph (headless CMS), Next.js, Algolia, in-house services, and legacy PIM systems. Hygraph's Content Federation allowed editors to access recipe and product data from multiple sources in one UI, supporting over 100 users globally. Note: This approach may require integration expertise and is best suited for organizations with complex, multi-market needs. Source.
Features & Capabilities
What are the key features of Hygraph relevant to microservices and composable architectures?
Hygraph offers a GraphQL-native architecture, Content Federation for integrating multiple data sources, enterprise-grade security and compliance (SOC 2 Type 2, ISO 27001, GDPR), Smart Edge Cache, localization, and granular permissions. It supports integrations with platforms like Algolia, Next.js, and various DAM and PIM systems. Note: Teams requiring deep customization of legacy monoliths may need additional migration planning. Source.
What integrations does Hygraph offer for composable and microservices-based stacks?
Hygraph integrates with Digital Asset Management (DAM) systems (Aprimo, AWS S3, Bynder, Cloudinary, Imgix, Mux, Scaleflex Filerobot), hosting platforms (Netlify, Vercel), Product Information Management (Akeneo), commerce solutions (BigCommerce), and translation/localization tools (EasyTranslate). For a full list, visit the Hygraph Marketplace. Note: Some integrations may require additional configuration or third-party subscriptions.
Implementation & Ease of Use
How long does it take to implement Hygraph in a composable or microservices-based architecture?
Implementation timelines vary by project complexity. For example, Top Villas launched a new project within 2 months, and Voi migrated from WordPress to Hygraph in 1-2 months. Hygraph offers structured onboarding, starter projects, and extensive documentation to accelerate adoption. Note: Highly customized or legacy migrations may require longer timelines. Source.
What feedback have customers given about Hygraph's ease of use?
Customers praise Hygraph's intuitive interface, quick adaptability, and accessibility for non-technical users. For example, Sigurður G. (CTO) noted the UI is intuitive for "normal people"; Anastasija S. (Product Content Coordinator) highlighted instant front-end updates; and Charissa K. (Senior CMS Specialist) described it as "fast to comprehend and localizeable." Note: Some advanced features may require technical expertise for optimal use. Source.
Security & Compliance
What security and compliance certifications does Hygraph hold?
Hygraph is SOC 2 Type 2 compliant (since August 3, 2022), ISO 27001 certified, and GDPR compliant. These certifications ensure high standards for information security management and data protection. Note: For industry-specific compliance needs, consult Hygraph's sales or security team. Source.
What security features does Hygraph provide for composable and microservices-based architectures?
Hygraph offers granular permissions, SSO integrations (OIDC/LDAP/SAML), audit logs, encryption in transit and at rest, regular backups with one-click recovery, and secure API policies (custom origin, IP firewalls). All endpoints have SSL certificates. Note: Some advanced security features may require enterprise plans. Source.
Performance & Scalability
How does Hygraph perform in high-scale, composable environments?
Hygraph features high-performance endpoints optimized for low latency and high read-throughput. Its read-only cache endpoint delivers 3-5x latency improvement. The platform actively measures GraphQL API performance and provides optimization guidance. Note: Actual performance may vary based on integration complexity and external service dependencies. Source.
Use Cases & Customer Success
What are some real-world examples of companies using Hygraph in composable or microservices-based architectures?
Notable examples include Dr. Oetker (global digital experience management), Prym (e-commerce with 100,000+ products), and Burrow (complex PIM and fulfillment integration). Other customers like Samsung, Komax, and Voi have achieved measurable business outcomes such as 3x faster time-to-market and 15% improved customer engagement. Note: Results depend on project scope and integration strategy. Source.
Which industries are represented in Hygraph's composable architecture case studies?
Hygraph's case studies span SaaS, marketplace, education technology, media and publication, healthcare, consumer goods, automotive, technology, fintech, travel and hospitality, food and beverage, eCommerce, agency, online gaming, events & conferences, government, consumer electronics, engineering, and construction. Note: Industry-specific requirements may affect implementation details. Source.
Pain Points & Limitations
What common pain points does Hygraph address for teams moving to composable or microservices-based architectures?
Hygraph helps reduce developer dependency, modernize legacy tech stacks, ensure content consistency, streamline workflows, lower operational costs, accelerate speed-to-market, and simplify schema evolution. It also addresses integration difficulties and performance bottlenecks common in complex, distributed systems. Note: Teams with highly specialized legacy systems may require additional migration planning. Source.
Technical Documentation & Support
What technical documentation is available for implementing Hygraph in composable or microservices-based architectures?
Hygraph provides API reference documentation, schema guides, getting started tutorials, integration guides (e.g., Mux, Akeneo, Auth0), and AI feature documentation. Classic documentation is available for legacy users. Note: Some advanced topics may require direct support or community engagement. Source.
Microservices in a composable architecture explained
We will detail what microservices are, how they differ from monolithic and composable architectures, when to use microservices, and examples of microservices in a composable approach.
Microservices have become an especially popular option to create scalable e-commerce systems and to support composable technology stacks that allow companies to mix-and-match capabilities from different best-of-breed tools instead of being locked into an inflexible set of features from a single software vendor.
Microservices are used to break business processes into discrete pieces, or services, that can be designed, improved, and scaled independently.
An example of a microservice in a metaphor would be:
Let’s say you have a birdhouse business. Making each house takes four steps: take the order, cut the wood, build the house, paint the house. At first, you hire one person to do all four steps and this works incredibly efficiently. As the business starts to grow, you simply scale up birdhouse production by hiring a small team where each person is responsible for the whole process.
Then things start to get more complex. Customers want birdhouses in different sizes and shapes, you find a more efficient way to cut wood or store tools, new paints hit the market, but updating the process to include these new things means retraining the whole team. So you bundle updates into a monthly training day when you close the store and get the team up to speed. Changing the process becomes such a hassle that you begin to settle for “good enough” birdhouses and when you have ideas for new offerings, like bird feeders or bird baths, the thought of expanding the process to include them is so daunting that you never even try.
So you decide to break up the process into those four distinct steps. You assign one person to take orders, one to cut wood, one to build houses, and one to paint. Each person can work autonomously, the person taking the order can just announce it and doesn’t need to wait for the woodcutter to respond before taking the next one, the carpenter can build the house without knowing how to paint it, and the painter can store art supplies in a completely different way than the carpenter stores nails.
This separation also means that each person can continuously make small improvements to their own ways of working without disrupting everyone else, so no more need to shut down the store for an all-company training. It also means you can scale up production more precisely, for instance to make 100 birdhouses a day you may only need one person to take orders but four people painting.
In other words, each microservice is:
Autonomous: A service can use the logic, programming language, and data storage that makes sense for the task. APIs are used to standardize how information is communicated between services.
Independently deployable: Changes to one service won’t impact the logic of another. Services can be updated continuously, and in parallel, without risking a cascade of errors across the system.
Individually scalable: Resources can be given to just the services that need it, allowing for more precise scaling strategies.
#Microservices vs composable vs monolithic architecture
Monolithic architecture
In a monolithic application all processes and capabilities are highly dependent on one another with a shared language, logic, and database. Due to this dependency, a change in one part of the system can have unintended consequences in another part of the system so updates are typically made in large batches leading to distinct versions of the application.
Small applications with simple processes work great as a monolith. Where companies start to run into problems is when a monolith sits at the core of a key part of business, like the digital experience, and over time there is a build up of clunky extensions and “one-off” workarounds that make the monolith expensive to maintain and hard to adapt to new customer demands.
Microservice architecture
A microservice architecture is on the other end of the dependency spectrum, where software is designed as a collection of small services each responsible for a distinct piece of business functionality such as checkout, inventory, blog, or even parts of the front-end. Each microservice is responsible for its own processes, database, and API. Changes can be made to one microservice without disrupting others, as long as it still shares data in an agreed upon way, so updates can happen on a rolling basis without versioning.
In a microservice architecture, the team structure is just as important as the technology. Typically each microservice is owned by a dedicated, cross-functional team that is responsible for developing, maintaining, and continuously improving the service.
Composable architecture
Composable and microservice architecture can sometimes be perceived as the same thing, but while microservices are usually a key component of a composable approach they aren’t the only type of solution used. Composability is the idea of creating a tech stack of best-fit tools for different areas of business and connecting them via APIs so solutions can be easily added, changed, and removed as needed.
A fully microservice architecture might be the end-goal of composable for some organizations, but the majority of composable architectures will be a mix of homegrown services, vendor solutions built with MACH principles (microservices, API-first, cloud-native, headless), and even some applications that are better left as a monolith.
#When and how to use a microservices based architecture
There’s no clear-cut guidelines for when a company should make the shift to microservices. Even Sam Newman, the author of the defining book on microservices, doesn’t have a straight answer:
If you want one quick answer for when you should use microservices, it’s when you’ve got a really good reason.
Even Sam NewmanAuthor at Building Microservices
Microservices can bring a lot of benefits, but can also add complexity, and teams that adopt them should do so only if the approach can deliver a needed business outcome. Some common business drivers include:
When you need your solution to evolve: Microservices have the flexibility to adapt to changing customer demands, diverse internal needs, and business pivots. Services can be composed in different ways to quickly spin up new ideas, and they make it easier to create a flexible tech stack that allows tools to be swapped in and out as business needs change.
When you need high availability: Microservices support a continuous development (CI/CD) approach and don’t require downtime for updates. With small services that are independently deployable you reduce the “blast radius” of any errors.
When you need to isolate data: With each microservice owning its own database there is more flexibility in separating data and the processes that touch it. This can be particularly useful for compliance standards such as the EU’s General Data Protection Regulation (GDPR).
When you need to enable autonomous teams: When large teams are working on complex monoliths, there is a massive coordination effort needed to make even the smallest change. If teams are already embracing DevOps but are being held back by legacy technology, microservices can enable teams to make quick decisions for their domain and move at the pace they’re ready for.
Even more so that “when” to implement microservices, “how” to do it is determined on a case-by-case basis. Here are some of the leading voices in the microservice space talking about key scenarios organizations need to consider when making the move:
How to get started with microservices: Martin Fowler, Microservices.
#Architecture example: microservices in a composable approach
The Oetker Group is Germany’s largest family run business, selling food and beverages across the globe. The organizations wanted to move to a composable architecture to make it easier for local teams to manage the digital experience for their market while keeping the global brand experience consistent.
To do this, the company took a headless approach. This gives each team the freedom to create unique front-end experiences for their market while sharing a centralized tech stack on the back-end. Dr. Oetker’s composable tech stack includes Hygraph (headless content management), Next.js (front-end framework), Algolia (search and discovery), in-house built services, and legacy applications for product information management (PIM) and storing recipe data.
Hygraph and Algolia are both microservice-based solutions, and the strong API support of these two platforms was key to bringing all the data together so that teams could manage the experience from one place. For instance, editors can use Algolia’s product discovery service directly in the Hygraph user interface (UI) to select and combine recipes, products, and articles to create better search results for customers.
Dr. Oetker also uses Hygraph’s Content Federation capabilities to retrieve recipe and product data and let editors easily access it from one UI. Data still lives in the recipe database and PIM, so there’s no worry about duplication. When data is requested the Hygraph API grabs the right information based on localization and permissions. This allows over 100 users to manage unique experiences for 40 different markets out of the same content management platform.
Hygraph is a certified MACH Alliance vendor and an advocate for a composable approach to software architecture where businesses are encouraged to pick the services and tools that best fit their needs.
Hygraph provides a next-generation content management platform with native GraphQL APIs that make it easy to integrate other tools in your stack. The platform’s novel approach to Content Federation also helps businesses solve the challenge of orchestrating data in a composable architecture.
The microservice structure of the platform gives businesses the flexibility to use Hygraph’s powerful functionality in different ways. Companies can leverage structured data models to unify data from their commerce stack into rich content, like the German craft-supplies company, Prym, does to create an e-commerce experience with over 100,000 unique products. Or can use Hygraph as a PIM and integrate it with fulfillment and payment solutions, like the American furniture company, Burrow, does to create highly complex data modeling structures to manage over 20,000 product variations.
Stop letting the limitations of your legacy monolith define your customer experience, and start designing a tech stack around the digital ambitions of your business. Learn more about a composable approach to Digital Experience Platforms in the DXP report.
Blog Author
Katie Lawson
Content Writer
Katie is a freelance writer based in Amsterdam who talks a lot about B2B SaaS and MACH technologies. She’s always looking for good book recommendations.
Share with others
Sign up for our newsletter!
Be the first to know about releases and industry news and insights.
Microservices in a composable architecture explained
We will detail what microservices are, how they differ from monolithic and composable architectures, when to use microservices, and examples of microservices in a composable approach.
Microservices have become an especially popular option to create scalable e-commerce systems and to support composable technology stacks that allow companies to mix-and-match capabilities from different best-of-breed tools instead of being locked into an inflexible set of features from a single software vendor.
Microservices are used to break business processes into discrete pieces, or services, that can be designed, improved, and scaled independently.
An example of a microservice in a metaphor would be:
Let’s say you have a birdhouse business. Making each house takes four steps: take the order, cut the wood, build the house, paint the house. At first, you hire one person to do all four steps and this works incredibly efficiently. As the business starts to grow, you simply scale up birdhouse production by hiring a small team where each person is responsible for the whole process.
Then things start to get more complex. Customers want birdhouses in different sizes and shapes, you find a more efficient way to cut wood or store tools, new paints hit the market, but updating the process to include these new things means retraining the whole team. So you bundle updates into a monthly training day when you close the store and get the team up to speed. Changing the process becomes such a hassle that you begin to settle for “good enough” birdhouses and when you have ideas for new offerings, like bird feeders or bird baths, the thought of expanding the process to include them is so daunting that you never even try.
So you decide to break up the process into those four distinct steps. You assign one person to take orders, one to cut wood, one to build houses, and one to paint. Each person can work autonomously, the person taking the order can just announce it and doesn’t need to wait for the woodcutter to respond before taking the next one, the carpenter can build the house without knowing how to paint it, and the painter can store art supplies in a completely different way than the carpenter stores nails.
This separation also means that each person can continuously make small improvements to their own ways of working without disrupting everyone else, so no more need to shut down the store for an all-company training. It also means you can scale up production more precisely, for instance to make 100 birdhouses a day you may only need one person to take orders but four people painting.
In other words, each microservice is:
Autonomous: A service can use the logic, programming language, and data storage that makes sense for the task. APIs are used to standardize how information is communicated between services.
Independently deployable: Changes to one service won’t impact the logic of another. Services can be updated continuously, and in parallel, without risking a cascade of errors across the system.
Individually scalable: Resources can be given to just the services that need it, allowing for more precise scaling strategies.
#Microservices vs composable vs monolithic architecture
Monolithic architecture
In a monolithic application all processes and capabilities are highly dependent on one another with a shared language, logic, and database. Due to this dependency, a change in one part of the system can have unintended consequences in another part of the system so updates are typically made in large batches leading to distinct versions of the application.
Small applications with simple processes work great as a monolith. Where companies start to run into problems is when a monolith sits at the core of a key part of business, like the digital experience, and over time there is a build up of clunky extensions and “one-off” workarounds that make the monolith expensive to maintain and hard to adapt to new customer demands.
Microservice architecture
A microservice architecture is on the other end of the dependency spectrum, where software is designed as a collection of small services each responsible for a distinct piece of business functionality such as checkout, inventory, blog, or even parts of the front-end. Each microservice is responsible for its own processes, database, and API. Changes can be made to one microservice without disrupting others, as long as it still shares data in an agreed upon way, so updates can happen on a rolling basis without versioning.
In a microservice architecture, the team structure is just as important as the technology. Typically each microservice is owned by a dedicated, cross-functional team that is responsible for developing, maintaining, and continuously improving the service.
Composable architecture
Composable and microservice architecture can sometimes be perceived as the same thing, but while microservices are usually a key component of a composable approach they aren’t the only type of solution used. Composability is the idea of creating a tech stack of best-fit tools for different areas of business and connecting them via APIs so solutions can be easily added, changed, and removed as needed.
A fully microservice architecture might be the end-goal of composable for some organizations, but the majority of composable architectures will be a mix of homegrown services, vendor solutions built with MACH principles (microservices, API-first, cloud-native, headless), and even some applications that are better left as a monolith.
#When and how to use a microservices based architecture
There’s no clear-cut guidelines for when a company should make the shift to microservices. Even Sam Newman, the author of the defining book on microservices, doesn’t have a straight answer:
If you want one quick answer for when you should use microservices, it’s when you’ve got a really good reason.
Even Sam NewmanAuthor at Building Microservices
Microservices can bring a lot of benefits, but can also add complexity, and teams that adopt them should do so only if the approach can deliver a needed business outcome. Some common business drivers include:
When you need your solution to evolve: Microservices have the flexibility to adapt to changing customer demands, diverse internal needs, and business pivots. Services can be composed in different ways to quickly spin up new ideas, and they make it easier to create a flexible tech stack that allows tools to be swapped in and out as business needs change.
When you need high availability: Microservices support a continuous development (CI/CD) approach and don’t require downtime for updates. With small services that are independently deployable you reduce the “blast radius” of any errors.
When you need to isolate data: With each microservice owning its own database there is more flexibility in separating data and the processes that touch it. This can be particularly useful for compliance standards such as the EU’s General Data Protection Regulation (GDPR).
When you need to enable autonomous teams: When large teams are working on complex monoliths, there is a massive coordination effort needed to make even the smallest change. If teams are already embracing DevOps but are being held back by legacy technology, microservices can enable teams to make quick decisions for their domain and move at the pace they’re ready for.
Even more so that “when” to implement microservices, “how” to do it is determined on a case-by-case basis. Here are some of the leading voices in the microservice space talking about key scenarios organizations need to consider when making the move:
How to get started with microservices: Martin Fowler, Microservices.
#Architecture example: microservices in a composable approach
The Oetker Group is Germany’s largest family run business, selling food and beverages across the globe. The organizations wanted to move to a composable architecture to make it easier for local teams to manage the digital experience for their market while keeping the global brand experience consistent.
To do this, the company took a headless approach. This gives each team the freedom to create unique front-end experiences for their market while sharing a centralized tech stack on the back-end. Dr. Oetker’s composable tech stack includes Hygraph (headless content management), Next.js (front-end framework), Algolia (search and discovery), in-house built services, and legacy applications for product information management (PIM) and storing recipe data.
Hygraph and Algolia are both microservice-based solutions, and the strong API support of these two platforms was key to bringing all the data together so that teams could manage the experience from one place. For instance, editors can use Algolia’s product discovery service directly in the Hygraph user interface (UI) to select and combine recipes, products, and articles to create better search results for customers.
Dr. Oetker also uses Hygraph’s Content Federation capabilities to retrieve recipe and product data and let editors easily access it from one UI. Data still lives in the recipe database and PIM, so there’s no worry about duplication. When data is requested the Hygraph API grabs the right information based on localization and permissions. This allows over 100 users to manage unique experiences for 40 different markets out of the same content management platform.
Hygraph is a certified MACH Alliance vendor and an advocate for a composable approach to software architecture where businesses are encouraged to pick the services and tools that best fit their needs.
Hygraph provides a next-generation content management platform with native GraphQL APIs that make it easy to integrate other tools in your stack. The platform’s novel approach to Content Federation also helps businesses solve the challenge of orchestrating data in a composable architecture.
The microservice structure of the platform gives businesses the flexibility to use Hygraph’s powerful functionality in different ways. Companies can leverage structured data models to unify data from their commerce stack into rich content, like the German craft-supplies company, Prym, does to create an e-commerce experience with over 100,000 unique products. Or can use Hygraph as a PIM and integrate it with fulfillment and payment solutions, like the American furniture company, Burrow, does to create highly complex data modeling structures to manage over 20,000 product variations.
Stop letting the limitations of your legacy monolith define your customer experience, and start designing a tech stack around the digital ambitions of your business. Learn more about a composable approach to Digital Experience Platforms in the DXP report.
Blog Author
Katie Lawson
Content Writer
Katie is a freelance writer based in Amsterdam who talks a lot about B2B SaaS and MACH technologies. She’s always looking for good book recommendations.
Share with others
Sign up for our newsletter!
Be the first to know about releases and industry news and insights.