What is microservice architecture? A guide to future-proof composable apps

Developers building back ends or modernizing legacy codebases can benefit from a microservice architecture: a way of developing efficient, scalable, and maintainable apps using independent, loosely coupled services.

Here’s what that actually means, explained in practical terms.

What is a microservice architecture?

The term “microservice architecture” describes the framework for developing applications that combine multiple autonomous, self-built or cloud-native tools to build out a loosely coupled tech stack that communicates using APIs. 

Each “microservice” in a modular, or composable, architecture serves a single purpose and is independently deployable. Ideally, they have well scoped domain responsibilities, are independently deployable, and can be scaled separately from all other services.

For example, an ecommerce app may be made up of individual services, separately handling payments, uploading product photos, generating the HTML front end, and sending order updates. Each service runs separately and communicates with the others to provide a complete online store.

This architecture enables DevOps teams to orchestrate tools from various vendors with self-built services, delivering a high-performing stack and more focused responsibilities. Rather than centrally orchestrating and deploying the communication and overlapping architectures and responsibilities of the services, microservices are individually managed by communicating with each other and independently deployed without impacting each other. This also means that multiple instances of the same services can be run so that if one fails, traffic can be sent to another for redundancy, or more services can be added with requests split between them for scalability.

The MACH (microservice-based, API-first, cloud-native, and headless) architecture is a popular microservices-based approach that is adopted for many new projects. It also serves as a path for migrating away from legacy monolith solutions. MACH architecture provides a framework to evolve a legacy monolith system into a more modern design by extracting each function of a monolith into separate services that can be individually managed and supported.

Why microservices matter

Monolithic architecture

A microservices-based app is an alternative to a monolith: a single codebase where the app is a single service containing all functionality in a single codebase.

The vertical stack of a monolithic application.

Service-oriented architecture

The mid-point between legacy monoliths and microservices was the service oriented architecture, which tried to replace monolithic features with individual, but still dependent, services. These were not free standing services and typically only spoke to a singular front end, while using the same data storage back end.

The mid-tier architecture of services sitting between a UI and data layer of the previous monolith solution.

Microservice architecture

Microservices matter to developers and tech leads, as they focus on resilience and cost-effectiveness and fully leverage the scalability of modern cloud services. Your users expect applications to be responsive in times of high demand, requiring ready scalability. They also expect regular feature updates and improvements, which means you need to be able to work on and test new ideas without affecting existing functionality. A microservices approach naturally enables this, helping you rapidly build modern, composable, API-first platforms and preventing technical debt.

How microservices can serve a user facing application by providing their own, self-contained ecosystem of APIs and storage.

Traditionally, development teams have relied on the monolithic model. This had its strengths: It’s easy to kickstart and typically the fastest way to launch an early-stage product. But monoliths can be difficult to scale and may lead development teams into rigid choices, making deployments risky since even a small change can impact the whole system.

What are the key differences between microservices and monolithic architectures?

Monolithic architectures and microservice architectures have several defining differences.

Structure

In a monolithic architecture, a single application with a relational codebase aggregates all the functionalities needed to create the application. In microservice architectures, multiple applications with different functions and codebases work together to support the creation of an application.

Deployment

Because monolithic applications encompass all functionality, continuous development often isn’t practical, and updates must be made in one large, scheduled motion. This downtime must be strategic so as not to impact users and could take significant time based on the size of the monolithic codebase and its requirements. Microservices — and their CI/CD pipelines — support scalable delivery by letting you update individual components in a staged manner, falling back if something goes wrong. This can make for faster, more granular deployments with less interruption.

Scalability and performance

Monoliths are best served by vertical scaling, which means simply adding resources to the server hosting the stack. This can be inefficient because the tight coupling requires that even if only a small portion of the monolith is serving 90% of users, the whole thing must be given more resources to cope with demand.

Microservices can each be vertically scaled, allowing each individual service to be given more resources. Here, the efficiency benefit is that only those services seeing more demand get extra resources, while services running with low demand remain with low resources.

Flexibility

Because monolithic applications are usually maintained by a single in-house team, they are typically slower to enhance than microservice applications. There usually isn’t the bandwidth to rapidly build out and launch high-performing tools or functionalities when new business needs arise. Rather than having the option to integrate a purpose-built tool from another vendor, monolithic platforms leave their developers with few options: either wait for a vendor to meet their needs or create a custom solution in-house.

Configuration and hosting

One advantage monolithic applications have over microservices is their ability to be used out of the box with little configuration or development. This is a strong selling point for companies creating basic applications and those with few developer resources. With microservice architectures, knowledge of how to properly connect and set up each tool — either from in-house developers or third-party digital agencies — is needed. This is, however, being increasingly addressed by tools such as Helm, Terraform, and Ansible for architecture orchestration, resource deployment, and configuration.

Fault tolerance

A singular monolithic codebase is, by its nature, tightly coupled, and with this comes the tendency for errors in one area to cause failures in another. A common example is resource allocation, such as memory consumption and connection pooling being shared by all functions of the application. Microservices are able to avoid this by having their own resourcing and, if designed to handle situations when dependencies fail, can limit the blast radius of problems.

Proper fault isolation depends on clear service boundaries, timeout handling, retries, and circuit breakers. Without these safeguards, failures in one service can still cascade into others, meaning microservices don’t guarantee fault tolerance on their own but can provide the framework to achieve it when designed well.

Team structure and autonomy

With each service broken from the original structure comes the opportunity to break out teams into smaller, focused units to support and enhance each microservice. This enables developers to specialize, teams to remain focused, and products to iterate faster. The team is free to choose the right tools for their build based on developer preference and the task at hand because each microservice is independent and can be written using a different language, framework, and libraries.

Key differences between monoliths and microservices

How to build with microservices: Best practices

As a developer or team lead, here are some practical things to consider before committing to microservices.

When to adopt microservices

If you are a small team looking to get up and running with a limited set of APIs and a tightly focused product, or you don’t have the time and resources to spread the load of multiple microservices (which are, in effect, their own applications), you may be better suited to a smaller monolithic application.

On the other hand, if you are a larger team, or distributed enough to support multiple sets of ownership, and your integration path demands the flexibility to plug in external systems and APIs, microservices may be your best fit. Evaluate your team strength and where you want to be with the architecture after the implementation period.

Pitfalls to avoid when implementing microservices

A common mistake is over-engineering too early. Slicing your codebase into dozens of services up front will inevitably slow development and migration rather than enabling your team to move faster.

Another mistake is poorly defined service boundaries or badly documented responsibilities. Get this wrong, and you end up with a larger version of the monolith, broken into even harder-to-debug applications that are not separate but tightly dependent. Insist on thoughtful, clear design choices from day one.

Real-world considerations

Building and running with microservices means choosing the right mix of tools and patterns to keep development efficient and systems resilient. Depending on the disciplines within your team, practical tools and options to consider include the following:

• Reliable CI/CD systems (Azure pipelines, GitHub Actions, etc.) to automate deployments.

• Scalable infrastructure, including container platforms (Docker, Kubernetes, AWS ECS, etc.) to provide scalability and consistency.

• For monitoring and debugging, observability stacks are critical: Frameworks like the open-source OpenTelemetry, platforms like Datadog or New Relic, and logging tools like the (also open-source) ELK Stack (Elasticsearch, Logstash, Kibana) or Splunk are common.

• Distributed tracing tools such as Jaeger (open source) or Zipkin help pinpoint issues across services.

• For APIs, REST remains the industry preference, but GraphQL is growing in adoption for flexibility, and event-driven patterns (Kafka, RabbitMQ, AWS EventBridge, etc.) enable asynchronous communication.

Microservices as the foundation of modern, composable, API-first platforms

When considering either starting from the ground up with a microservice architecture or using it as a migration goal, consider the microservices as the groundwork for an API-first, composable platform. A clear vision with well-documented APIs makes them the contracts between your new services. This is what will let you swap out services, integrate new tools and services quickly, and avoid technical debt and vendor lock-in. 

Each microservice should have a clear domain responsibility. This reduces overlap and keeps teams focused on owning their domain’s feature set. By following DevOps best practices, giving each team control over their CI/CD pipeline, testing, and deployments, each microservices development team can work independently, and faster iteration and releases can be accomplished.

Furthermore, you can reduce complexity and technical debt by adhering to MACH principles:

• Microservice: Break problems into focused, loosely coupled services.

• API-first: Design the integration before the implementation.

• Cloud-native: Leverage the managed nature of cloud providers and benefit from their provided scaling and resiliency.

• Headless: Decouple the frontend (including releases) from the backend logic (and, of course, its releases).

How to break monolith applications into microservices

Many successful teams begin with a monolith and migrate gradually, such as with the “strangler fig” pattern: New functionality is built as separate services and used to slowly replace legacy parts of the larger whole. This reduces risk and lets teams adapt to the new architecture at a sustainable pace. 

Pair this with domain-driven design that ensures that each service aligns with a clear capability, and you’ll have a roadmap that balances stability with modernization. Below, you can see how an application can be broken up into scalable component services, data storage, and third-party SaaS APIs that add additional functionality that doesn’t require additional development resources:

The key steps to migrating from a monolith to a microservice-based architecture are:

1. Assess and design: Identify business domains and bottlenecks and set clear service boundaries.

2. Pick a starting point: Choose a small, high-value feature to extract first.

3. Build infrastructure: Put CI/CD, containers, and monitoring in place.

4. Migrate incrementally: Use the strangler fig approach to extract and connect services one by one.

5. Retire the monolith: Gradually refactor and decommission old components as services take over.

Real-world examples of the benefits of a microservice architecture

Global technology companies and service providers, including Amazon, Netflix, Spotify, and Uber, have made their preference for MACH architectures well known. But it’s not just the big players that have made the move to microservices — many startups and small-to-mid-sized businesses have had success refactoring to microservice architectures.

VR Group

VR Group modernized a disjointed ticketing system, improved team and customer experiences, and unified its stack by swapping out its ecommerce monolith for a microservice architecture that roped in Contentful, Mapbox, and other tools.

Its developers are taking full advantage of the architecture’s flexibility in frameworks and languages by utilizing Gatsby for static sites, React for web apps, React Native for mobile, and Java on the back end, in addition to GraphQL and TypeScript. The fluidity and flexibility of its new architecture inspire continuous optimization and have led to a 50% increase in the app’s net promoter score.

Staples Canada

Staples Canada was outgrowing the targeted capabilities of its Shopify-powered ecommerce platform. By instead making Shopify a component of a new microservice architecture, Staples Canada was able to stay competitive by shipping perfectly timed campaigns during big holidays and creating fully optimized content localized with support from choice integrations.

Costa Coffee

When Costa Coffee was acquired by Coca-Cola, it re-platformed its legacy CMS to a microservice architecture in just five weeks. The stack, which relies on JavaScript, GraphQL, and Netlify, also integrates services from Akamai, Buddy, Google Maps, Google Translate, Adobe Target, Adobe Data, and Storybook. This robust and agile tech stack can launch localized sites in 15 minutes, with more than a dozen sites live today. It also powers Costa Club, the Costa Coffee customer rewards app. 

When adopting a microservice architecture, it’s important to consider how you’ll measure and share its success to promote continued use down the road. Check out our framework for assessing the performance of new architectures for guidance in this area.

How does Contentful support microservice architectures?

When it comes to building microservices, the applications introduced vary from company to company and are based on business needs, projects, and industry. The common thread is that all digital experiences and applications need content. As an digital experience platform, Contentful delivers extensibility, flexibility, and speed. It easily unites third-party and custom-built tools and streamlines their reuse of content structure. The Contentful Content Delivery API allows content within the platform to be accessed and displayed within other applications, providing content management and hosting to your microservices-based app without you having to write the backend code yourself. 

The Contentful Content Preview API fulfills a similar role but specifically addresses unpublished content. It displays drafted or recently published but not yet deployed content in its frontend format for review. The Contentful Content Management API and the Contentful Images API share content updates across applications and manage digital asset delivery and transformation. In Contentful, the decoupled content layer functions like a shared service in a microservice architecture, centralizing content in one place while exposing it through APIs for multiple sites, apps, and channels. This ensures that content is consistent and reusable across microservices, as well as your brand’s entire digital presence.

There are other Contentful features that extend microservice architecture benefits:

• The Contentful App Framework and extensive tooling allow you to integrate a content platform into your existing tech stack, add new third-party or custom-built services, and customize the Contentful UI to optimize editorial experiences for content creators, tailor workflows, and launch one-of-a-kind apps that address unique business needs.

• Contentful has well-documented APIs that extend beyond the core APIs outlined previously to include the Content Delivery API, Content Management API, Content Preview API, Images API, GraphQL Content API, User Management API, and SCIM API. Everything stored in the platform is secure and just an API call away.

• The Contentful Forma 36 design system is open source and makes quick work of customization so that it looks great to not just end users but non-technical team members by reducing the developmental overhead associated with creating the UI of custom-built apps or extending functionalities within Contentful.

• Contentful is a fully managed service, so it already scales and you don’t need to worry about security or infrastructure maintenance, including uptime, backups, and compliance. Your teams can focus entirely on building features rather than running the platform.

The Contentful App Marketplace includes a library of function-specific microservices that can be added to your tech stack with the click of a button. To view specific tools within each category, click on the category name. Once you’ve explored the Marketplace, you can create a free Contentful account and start building.

Many companies have transitioned from monolithic to microservice architectures with help from Contentful and, when they wanted a little extra guidance and implementation help, a partnered digital agency.

Microservices and a composable architecture: flexible, collaborative, and future-proof

The microservice architecture benefits developers, stakeholders, and end users by providing a more easily maintainable codebase, reliable and cost-effective deployment, and a responsive experience. It also recognizes and enables the advantages of a composable architecture, in which independent, API-driven, third-party services like Contentful can be readily integrated, making it fast to adapt and add new functionality as your business needs evolve.

Contentful can be integrated with any app or service using its well-documented REST and GraphQL APIs and SDKs for popular languages and frameworks, providing a content layer that decouples content from presentation and makes it reusable across apps, sites, and devices. Start building with Contentful for free today.

Start building

Sign up for a free Contentful account

Use your favorite tech stack, language, and framework of your choice.

Inspiration for your inbox

Subscribe and stay up-to-date on best practices for delivering modern digital experiences.