# What Are Microservices? Meaning, Examples, vs Monolith

> Microservices split one app into small, independently deployable services. Learn how they work, an example, monolith vs microservices, pros, and challenges.

**URL:** https://www.ciptadusa.com/blog/microservices-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Engineering  
**Published:** 2026-11-01  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-11/1793499925681-microservices-adalah-20261101.webp  

## Article

Microservices is a software architecture style that builds a single application as a suite of small services. Each service runs in its own process, owns one business capability (orders, payments, or inventory, for example), and talks to other services through lightweight mechanisms such as an HTTP API. James Lewis and Martin Fowler set out this definition in their 2014 article, which also notes that each service can be deployed independently through fully automated deployment ([source](https://martinfowler.com/articles/microservices.html)).

The opposite is a monolithic architecture: one codebase that runs many business functions and is deployed as a single unit ([source](https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/)). This article covers what microservices are, how they work, an example, how they differ from a monolith, their benefits and challenges, and how to judge whether your business application actually needs them.

## What Are Microservices?

Microsoft's Azure Architecture Center describes microservices as small, independent, and loosely coupled components that a single small team of developers can write and maintain. Each service has its own codebase, can be updated without rebuilding the entire application, persists its own data, and hides its internal implementation behind an API ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)).

The term "microservice" came out of a workshop of software architects near Venice in May 2011, and the same group settled on "microservices" as the name in May 2012 ([source](https://martinfowler.com/articles/microservices.html)).

### Microservices Are Not Just "a Smaller App"

Code size is not the point. Lewis and Fowler list nine characteristics they saw in microservice systems ([source](https://martinfowler.com/articles/microservices.html)):

- Componentization via services rather than libraries.
- Services organized around business capabilities, not technical layers.
- Teams own products for their whole life, not just until a project ends.
- Smart endpoints and dumb pipes.
- Decentralized governance.
- Decentralized data management.
- Infrastructure automation.
- Design for failure.
- Evolutionary design.

The authors state that not every microservice architecture has all nine. Read the list as a pattern, not a formal checklist.

## How Microservices Work

In a microservices architecture, a single user request can call several internal services whose results are composed into one response ([source](https://cloud.google.com/architecture/microservices-architecture-introduction)). The main building blocks are:

- **API gateway.** A single entry point for all clients that routes each request to the right service ([source](https://microservices.io/patterns/apigateway.html)). Microsoft recommends keeping business logic out of the gateway and using it for cross-cutting concerns such as authentication and SSL termination ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)).
- **Domain services.** Each one owns a business capability and exposes an [API](/en/blog/api-adalah), with data sent in formats such as [JSON](/en/blog/json-adalah).
- **Database per service.** A service's data is private to it and accessible only through its API ([source](https://microservices.io/patterns/data/database-per-service.html)).
- **Message broker.** Platforms such as Apache Kafka or Azure Service Bus handle asynchronous, event-based communication ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)). The idea resembles a [webhook](/en/blog/webhook-adalah), but inside the system.
- **Container orchestration.** Kubernetes is an open source platform for managing containerized workloads and services, including service discovery, load balancing, and self-healing ([source](https://kubernetes.io/docs/concepts/overview/)).
- **Observability.** Because one transaction crosses many services, logs, metrics, and traces must be collected centrally. OpenTelemetry is a framework and toolkit for generating and collecting that telemetry ([source](https://opentelemetry.io/docs/what-is-opentelemetry/)).

### Example: Microservices for a Distributor App

The following is an illustration prepared by CDS to show how services can be split, not the design of a specific project. Picture an ordering app for a distributor split into these services:

| Service | Responsibility | Data it owns |
| --- | --- | --- |
| Customers | Store details, addresses, credit limits | Customer tables |
| Catalog | Products, prices, units | Product and price tables |
| Orders | Creating and tracking orders | Order tables |
| Inventory | Stock reservation and warehouse movements | Stock tables |
| Payments | Invoices and payment status | Invoice tables |
| Notifications | Sending email or WhatsApp messages | Delivery logs |

When a store places an order, the Orders service saves it and publishes an "order created" event. Inventory reserves the goods, Payments creates the invoice, and Notifications sends a confirmation. If the stock reservation fails, the completed steps are undone with compensating actions. This pattern is called a saga: a coordinated sequence of local transactions, driven either by events (choreography) or by one orchestrator (orchestration) ([source](https://microservices.io/patterns/data/saga.html)).

In a monolith, the same flow can run inside a single database transaction. That difference is why microservices are more complex than they look.

## Microservices vs Monolithic Architecture

CDS compiled the table below from the AWS, Microsoft, and IBM guides linked underneath it.

| Aspect | Monolith | Microservices |
| --- | --- | --- |
| Codebase | One codebase for every function | A separate codebase per service |
| Deployment | The whole app is deployed together | Each service is deployed on its own |
| Scaling | The whole app scales together | Busy services can scale on their own |
| Database | One shared database | Data private to each service |
| Transactions | One database transaction (ACID) | Eventual consistency, saga pattern |
| Debugging | More direct, one process | Needs tracing across services |
| Infrastructure needs | Simple | Automated deployment, monitoring, orchestration |
| Fits | Simple apps, prototypes, small teams | Complex systems with many teams |

Sources: [AWS](https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/), [Microsoft](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices), [IBM](https://www.ibm.com/think/topics/monolithic-vs-microservices).

AWS writes that the monolithic approach is more suitable for a simple application or prototype, while microservices are better for building complex systems ([source](https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/)). IBM adds that a monolith has the edge in time to market and debugging, while microservices have the edge in scalability ([source](https://www.ibm.com/think/topics/monolithic-vs-microservices)).

### The Modular Monolith Middle Ground

There is a third option: a modular monolith, a single application with strictly enforced boundaries between domains. Shopify took this route for its Ruby on Rails codebase. In a 2019 engineering post, Shopify wrote that microservices would bring their own set of challenges, so it kept all code in one codebase while enforcing boundaries between components ([source](https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity)). In 2020 it reported that this core monolith held over 2.8 million lines of Ruby code and 500,000 commits ([source](https://shopify.engineering/shopify-monolith)).

The lesson: application size alone is not an automatic reason to move to microservices.

## Benefits of Microservices

Microsoft's architecture guide lists these benefits ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)):

- **Focused small teams.** One feature team can build, test, and deploy a service.
- **Smaller codebases.** New features do not touch many tangled parts of the code.
- **Mix of technologies.** Each team can pick the stack that fits its service.
- **Fault isolation.** One unavailable service does not take down the whole app, as long as upstream services handle the failure, for example with the circuit breaker pattern.
- **Independent scaling.** Parts that need more resources can grow without scaling everything.
- **Data isolation.** Schema changes affect only one service.

## Challenges and Drawbacks of Microservices

The same guide states that each service is simpler, but the system as a whole is more complex ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)). The challenges it names:

- **System complexity.** Service discovery, data consistency, transaction management, and interservice communication all need design.
- **Development and testing.** Refactoring across service boundaries is hard, and testing service dependencies is challenging.
- **Governance.** Too many languages and frameworks make the app hard to maintain.
- **Network latency.** A chain of calls from A to B to C adds delay.
- **Data integrity.** A change spanning several services cannot be treated as one ACID transaction.
- **Operations.** A mature DevOps culture and logs correlated across services are required.
- **Versioning.** Updating one service must not break the services that depend on it.
- **Team skills.** Microservices are a distributed system, so the team needs matching experience.

Martin Fowler calls this extra cost the microservice premium: added cost and risk that only pays off when the system is genuinely complex ([source](https://martinfowler.com/bliki/MicroservicePremium.html)).

### Prerequisites Before Adopting Microservices

Fowler also writes that teams without three baseline competencies should not consider the microservice style ([source](https://martinfowler.com/bliki/MicroservicePrerequisites.html)):

1. **Rapid provisioning.** A new server can be fired up in a matter of hours.
2. **Basic monitoring.** Errors, service availability, and business signals such as a drop in orders are detected quickly.
3. **Rapid application deployment.** An automated deployment pipeline to test and production environments.

All three map directly to [DevOps](/en/blog/devops-adalah) practice.

## When Does a Business Need Microservices?

Fowler writes that almost all the successful microservice stories he heard started with a monolith that grew too big and was broken up, while almost all the systems he heard of built as microservices from scratch ended up in serious trouble. The reason: good service boundaries are hard to get right at the start, and moving functionality between services is much harder than inside a monolith ([source](https://martinfowler.com/bliki/MonolithFirst.html)).

Organization matters too. Melvin Conway wrote in 1968 that any organization that designs a system will produce a design whose structure copies the organization's communication structure ([source](https://www.melconway.com/Home/Conways_Law.html)). If you have only one development team, splitting the app into many services does not automatically give you independent teams.

The questions below are an internal CDS guide for assessing the need, not a formal rule:

| Question | If "yes" | If "no" |
| --- | --- | --- |
| Do several teams need to release features independently? | Consider microservices | A monolith or modular monolith is enough |
| Does one part of the app carry a very different load from the rest? | That part is a candidate for its own service | Scale the whole app |
| Are business domain boundaries clear and stable? | Splitting is safer | Tidy up modules in the monolith first |
| Are deployment, monitoring, and provisioning automated? | Prerequisites are met | Build the DevOps foundation first |
| Can consistency between modules lag for a short while? | Events and sagas are an option | Keep one transactional database |

## How to Migrate from a Monolith to Microservices

If the monolith is genuinely holding you back, a gradual approach is safer than a full rewrite. Fowler popularized the term Strangler Fig for gradual legacy modernization: new functionality grows around the old system until the old system can be retired ([source](https://martinfowler.com/bliki/StranglerFigApplication.html)).

The steps below are an internal CDS guide:

1. **Map the business domains.** Identify bounded contexts, the natural divisions in a business within which a domain model applies ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)).
2. **Tidy up modules inside the monolith.** Remove cross-access to tables owned by other modules.
3. **Put a gateway or [middleware](/en/blog/middleware-adalah) layer** in front of the monolith so traffic can be rerouted feature by feature.
4. **Extract one service first.** Pick one with a clear boundary and low risk, such as notifications.
5. **Split the data.** This is the hardest part and needs its own [data migration](/en/blog/migrasi-data-adalah) plan.
6. **Test and monitor.** Run integration tests and [UAT](/en/blog/uat-adalah), then watch errors and latency before moving the next service.

Microsoft also lists antipatterns to avoid, including services that are too fine-grained, sharing libraries or database schemas between services, and exposing services directly to clients without a gateway ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)).

## Microservices in CDS Projects

On the [custom software development](/en/services/software) page, CDS states that the stack is chosen per project based on needs, the internal team's skills, and long-term operating cost. The same principle applies to architecture: microservices are one option, not a mandatory starting point. For applications already in production, CDS [IT consulting](/en/services/consulting) covers system and code audits, architecture design with module separation, and a phased migration path.

CDS's own product, [Zetta CRM](/en/incubating/zetta-crm), is a Go-based MCP server shipped as a single binary with one MySQL database and a `POST /mcp` endpoint. A single-unit design like this keeps the product easy for a small team to self-host, in line with the monolith-first reasoning above.

To understand the other layers of an application architecture, see also [backend](/en/blog/backend-adalah), [frontend](/en/blog/frontend-adalah), and [system integration](/en/blog/integrasi-sistem-adalah).

## Microservices FAQ

### What are microservices in simple terms?

Microservices are a way to build an application as a set of small services, each handling one business function, owning its own data, and communicating with the others through APIs ([source](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices)).

### What is a microservices architecture?

A microservices architecture is an application architecture style that splits one large application into independent parts, each with its own responsibility, that can be developed and deployed separately ([source](https://cloud.google.com/architecture/microservices-architecture-introduction)).

### What is the difference between a monolith and microservices?

A monolith uses one codebase and is deployed as one unit, while microservices consist of separate services that are deployed and scaled individually ([source](https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/)).

### Are microservices always better than a monolith?

No. Microservices add cost and risk that only pay off for complex systems ([source](https://martinfowler.com/bliki/MicroservicePremium.html)). For a simple application or prototype, AWS considers a monolith more suitable.

### Do microservices require Kubernetes?

No. Kubernetes helps with container orchestration, service discovery, and self-healing ([source](https://kubernetes.io/docs/concepts/overview/)), but microservices can run on other platforms, including managed container services such as Azure Container Apps, which Microsoft mentions.

### What is a microservices developer?

A microservices developer is a backend developer who builds and maintains services in a microservices architecture: designing APIs, managing per-service data, handling asynchronous communication, and setting up deployment and monitoring for each service.

## Not Sure Your App Needs Microservices?

Splitting an app too early can raise operating costs, while waiting too long can slow feature releases. The CDS team can audit your system and draft a target architecture with phased steps through [IT consulting](/en/services/consulting), build it through [custom software development](/en/services/software), or you can browse [CDS works](/en/works) first.


---

*Markdown version of https://www.ciptadusa.com/blog/microservices-adalah — generated for AI agents and LLM crawlers.*