Microservices architecture builds one application as a set of small, independent services, and each service owns one business job. Teams release and scale each service on its own, which is the main reason the style is popular. This guide explains how microservices work with a diagram and an example, then gives a test for when to use it on a custom software development project.
What are microservices?
Microservices split one application into small services that deploy and scale independently. Each service covers one business capability, such as payments or product search, and talks to the others through APIs or messages. The Azure Architecture Center lists the same traits, such as services small enough for one feature team and no shared data stores.
Microservices are one style of software architecture, the set of structural decisions that shape how a system is built. The opposite style is the monolith, in which the whole application ships as one unit.
How the services connect, in a diagram
In a microservices diagram, clients reach the services through one API gateway, and each service keeps its own data store. The diagram below shows an online store with four services: catalog, cart, orders, and payments. A message broker carries events between the services, and a side strip shows the platform that runs and monitors them.
Read the diagram from top to bottom. A request enters at the gateway, a service handles it, and any follow-up work travels as an event.
The parts of a microservices system
Five parts do most of the work in a microservices system: the services, an API gateway, data stores, messaging, and the platform that runs and watches them.
| Component | What it does | Why it exists |
| Services | Each runs one business capability and can be deployed alone | Keeps changes small and local |
| API gateway | The single entry point that routes client requests to services and handles shared jobs such as authentication | Stops clients from calling every service directly |
| Data stores | Each service owns its data and schema | Stops one schema change from breaking other services |
| Messaging | A broker passes events between services so they do not have to wait for each other | Keeps services loosely coupled |
| Platform | Orchestration starts and restarts services, and observability tools collect logs and traces | Keeps many services running and visible |
Microservices architecture usually does not include the user interface. In TekRevol’s reading, the web or mobile interface sits outside the services as a client that calls the gateway, although some teams split the interface by service too.
How do microservices communicate with each other?
Microservices communicate in two ways: directly through APIs, or indirectly through messages. A direct call waits for the answer, and a message does not.
| Style | How it works | Use it when | Cost |
| Synchronous (API call) | One service calls another and waits for the reply | The caller needs the answer to continue, such as a payment approval | Delays and failures pass back up the chain |
| Asynchronous (message or event) | A service publishes an event to a broker, and others react later | Several services must react to one change, such as a confirmed order | Data updates reach services at different times |
The API gateway sits between clients and services, and service discovery lets one service find the current address of another. Many small services also mean many network calls, so avoid chatty APIs and use messages where no reply is needed.
Microservices design: four decisions every team makes
Microservices design comes down to four decisions: where to draw service boundaries, who owns the data, how services communicate and how failures are contained.
| Decision | Question to answer | Common mistake |
| Boundaries | Which business capability does each service own? | Splitting before the business domain is understood |
| Data ownership | Which service is the single owner of each piece of data? | Several services sharing one database schema |
| Communication | Which calls must wait for a reply, and which can be events? | Long chains of synchronous calls |
| Failure handling | What happens when a service is slow or down? | No timeouts, so one slow service drags down the rest |
The decisions rest on two plain rules: organize services around the business and give each service its own data. In practice, one service owns each piece of data, and other services reach it only through that service’s API, and our guide to microservices design patterns explains them.
An online grocery order, step by step
In this microservices example, an online grocery order passes through six services, and a slow payment does not stop the rest of the store. The example is TekRevol’s illustration and uses no real numbers. A real store would have more services and more rules.
| Service | What it owns | How it talks to others |
| Catalog | Products and prices | Answers lookups from the cart through its API |
| Cart | The shopper’s basket | Calls the catalog for prices and hands the basket to orders |
| Orders | Order records and status | Calls payments, then publishes an “order confirmed” event |
| Payments | Charges and refunds | Replies to the orders service through its API |
| Delivery slots | Available time windows | Listens for “order confirmed” and reserves a slot |
| Notifications | Email and push messages | Listens for “order confirmed” and sends a receipt |
The shopper checks out, and the orders service asks payments to charge the card and waits for the reply, because it cannot confirm an order without one. Once the charge succeeds, orders publishes one event, and the delivery and notification services react on their own. If payments is slow, the orders service times out and asks the shopper to retry, while other shoppers keep browsing the catalog.
Benefits of microservices
The main benefit of microservices is independence: each service can be released and scaled without touching the rest. Microsoft’s architecture guidance describes these benefits:
- Independent deployment. A bug fix or feature ships in one service, and a single service can be rolled back without redeploying the whole application.
- Independent scaling. Only the busy services get more resources.
- Fault isolation. A failed service does not have to take down the application if the other services handle the failure well.
- Small teams. A service is small enough for one feature team to own.
- Technology choice. Each service can use the language and data store that suit it.
Disadvantages of microservices
The main disadvantage of microservices is complexity, because a distributed system has more moving parts than one codebase. Weighing the pros and cons of microservices means counting these costs against the independence the style buys.
- Data consistency. Each service owns its data, so a change that spans several services is applied in steps and is usually eventually consistent.
- Network delays. Many small services make many calls, and long chains of calls add latency.
- Running many services needs mature automation and a DevOps culture, and tracing one request across services is hard.
- A change to one service must not break the services that depend on it.
- Testing and refactoring across services are harder than inside one codebase.
- Teams need experience with highly distributed systems.
Microservices vs monolith
A monolith ships as one deployable unit, and microservices ship as many small ones. The table compares the two styles on the points teams ask about most.
| Aspect | Monolith | Microservices |
| Deployment | The whole application is released together | Each service is released on its own |
| Scaling | The whole application scales as one | Only the busy services scale |
| Data | Usually one shared database | Each service owns its data |
| Failure impact | A fault can affect the whole application | A fault can stay inside one service |
| Speed at the start | Fast to build and run | Slower, with more setup and tooling |
| Team fit | One team or a few teams | Several teams working independently |
Microservices are one of several software architecture patterns, and the right pick depends on the product and the team. For a fuller side-by-side, see TekRevol’s guide to monolithic vs microservices.
Service-oriented architecture (SOA) also splits a system into services. In TekRevol’s reading, the SOA vs microservices difference is mostly size and data. SOA services are usually larger and often share a central database, while microservices stay small and own their data.
Should you start with a modular monolith?
In TekRevol’s judgment, starting with a modular monolith is often the safer choice for a new product. A modular monolith is one deployable application whose code is divided into modules with clean boundaries.
Martin Fowler’s Monolith First argument, published in 2015, makes the same case: early on, speed and feedback matter most, and service boundaries are hard to get right before the product is understood. He notes that many successful microservice systems began as monoliths, and he says his evidence is limited.
In TekRevol’s judgment, the choice between a modular monolith and microservices is not permanent. Fowler cautions that tangled monoliths are hard to split, so keep the module boundaries clean from the start and split out a service when a module needs its own release schedule or its own scaling.
When to use microservices: the TekRevol Service Split Check
Use microservices when several teams must release independently, and your operations are mature enough to run many services. The TekRevol Service Split Check turns that into five questions, and the check is TekRevol’s judgment.
| Question | Points to separate services | Points to a modular monolith |
| Do several teams need to release on their own schedules? | Yes, teams block each other today | No, one team releases everything together |
| Do parts of the system have very different load? | Yes, one part needs far more capacity | No, load is similar across the product |
| Can you run many services? | Yes, deployment is automated and monitoring is in place | No, releases and monitoring are still manual |
| Are the business boundaries clear and stable? | Yes, the domain is well understood | No, the product is still changing shape |
| Does the data split cleanly? | Yes, each area has its own data | No, most features need the same tables |
Four or five answers in the middle column point to separate services, and four or five in the last column point to a modular monolith. Anything in between suggests splitting out one or two services first and keeping the rest together. A longer checklist of microservices best practices builds on the same decisions.
Planning microservices or splitting an existing monolith?
TekRevol, a software development company, helps at both ends of this decision: choosing the structure for a new product and moving an existing application toward services. TekRevol’s custom software development process includes a Design stage that covers architecture planning, workflow mapping, database schema and API structure, followed by two-week agile sprints.
For an existing monolith, TekRevol’s cloud application development services include containerized microservices on Docker and Kubernetes, and migration by re-platforming or re-architecting the application. Bring your product plan and the constraint that worries you most, such as slow releases.
Choose services for the problems you have today. Get a Free Consultation.
