Microservices design patterns are established solutions to the problems that appear once an application is split into many small services. Each pattern pairs a problem with a fix, so a team does not have to invent one.
This guide sorts the patterns by the problem they solve instead of by name, and it shows what goes wrong when you skip each one in a custom software development project. The sorting is TekRevol’s judgment, and the sources support each pattern.
What are design patterns in microservices?
A microservices pattern is a reusable solution to a design problem that recurs in systems built from small, independent services. A problem such as keeping data consistent across two services has the same shape in every project, so a named pattern saves each team from solving it again. For patterns that cover other architecture styles, see TekRevol’s guide to software architecture patterns.
You will also see them called microservice patterns or microservices architecture patterns. They sit on top of the microservices architecture style, and they follow from two microservice design principles: organize services around business capabilities, and give each service its own data store.
How many design patterns are there in microservices?
There is no fixed number, because each catalog counts and groups patterns in its own way. As of 2026, Microsoft’s microservices guidance named eleven main patterns plus two supporting ones, and the microservices.io pattern language spread a much longer list across more than a dozen problem-based groups.
| Catalog | How it is organized | Best used for |
| Microsoft Azure Architecture Center | A short list of microservices patterns, plus a wider cloud patterns catalog | Looking up one pattern’s problem and fix |
| microservices.io | A pattern language grouped by the question a team faces, such as how to decompose an application into services | Finding the right pattern for a problem |
The last column is TekRevol’s reading. Use a catalog as a reference, because a small system needs only a handful of patterns. The rest of this guide covers the ones that come up most often.
The TekRevol Pattern Selector: pick by problem
The TekRevol Pattern Selector starts with the problem you have and only then names a pattern. The selector sorts the patterns into five problem areas, and each area has one question to ask. The selector is TekRevol’s judgment.
| Problem | Question to ask | Patterns to look at |
| Splitting the system | Where do the service boundaries go, and how does a team move there from an existing system? | Decompose by business capability, strangler fig, anti-corruption layer |
| Owning data | Which service owns each piece of data, and how do changes stay consistent? | Database per service, saga, CQRS, event sourcing |
| Communicating | How do clients reach services, and how do services reach each other? | API gateway, backend for frontend, publisher-subscriber, service discovery |
| Surviving failure | What happens when a service is slow or down? | Timeout, retry, circuit breaker, bulkhead |
| Running and securing | How do shared jobs such as logging and security reach every service? | Sidecar, gateway offloading, access token |
Read the table row by row and stop at the first row where you have a real problem. In TekRevol’s judgment, most systems need patterns from one or two rows.
Decomposition patterns: how to split the system
Split by business capability first, and use the strangler fig pattern when you are replacing an existing system. Decomposing by business capability gives each service a job that a business person can name, such as payments or catalog. The microservices.io catalog also lists decomposing by subdomain, which draws boundaries from the subdomains of a domain-driven design.
| Pattern | Use it when | Failure if skipped |
| Decompose by business capability | You are drawing boundaries for a new system | Services split by technical layer, so one feature needs changes in many services |
| Strangler fig | You are replacing a legacy system piece by piece | A big-bang rewrite that cannot ship until everything is done |
| Anti-corruption layer | A new service must talk to a legacy system with an incompatible model | The legacy model leaks into the new service’s design |
The failure column is TekRevol’s reading. In the strangler fig pattern, consumers keep the same interface while functionality is replaced behind it, which is why it suits a gradual move off a legacy system.
Microservices database design patterns
Give each service its own data first, then add a saga or CQRS only where that rule creates a new problem. The database per service pattern means other services reach the data only through the owning service’s API, so a schema change stays inside one service.
Private data creates two problems. A change that spans services cannot use one transaction, and a query that spans services cannot use one join. A saga replaces the single transaction with a series of local steps that can each be undone, and CQRS answers the query problem. In TekRevol’s reading, API composition answers it as well.
| Pattern | Use it when | Trade-off |
| Database per service | Always, as the default | Data is duplicated or fetched across services, and cross-service joins disappear |
| Saga | One business action changes data in several services | Every step needs an undo, so there is more to design |
| API composition | A query needs data from several services | Slower when many services are called |
| CQRS | Reads and writes have very different needs | Two models to keep in step, with a delay between a write and the read |
| Event sourcing | You need a full history of changes | Current state is harder to query |
The trade-offs are TekRevol’s reading. Microsoft describes the saga as a way to keep data consistent across services without distributed transactions.
Communication patterns: how services and clients talk
Put an API gateway in front of clients, and use messaging when a caller does not need a reply. Microsoft’s guidance describes a gateway that gives clients one endpoint and can combine several requests into one, which cuts chatty calls between clients and services.
When web and mobile clients need different data, a backend for frontend gives each client type its own backend. TekRevol’s guide to microservices for mobile app backends covers the mobile case in more depth.
| Pattern | Use it when | Failure if skipped |
| API gateway | Clients should see one endpoint | Clients call many services directly and depend on their internal details |
| Backend for frontend | Web and mobile need different responses | One backend tries to serve the conflicting needs of different clients |
| Publisher-subscriber | Several services react to one event | The sender must know about every receiver and call each one |
| Service discovery | Service addresses change as instances start and stop | Hardcoded addresses break when an instance moves |
Resilience patterns: how to contain failure
Set a timeout on every call first, then add a retry with limits and a circuit breaker. Add bulkheads when one workload can starve another. Timeout is not a named pattern in the catalogs, but TekRevol lists it because the others depend on it.
Microsoft’s guidance lists retry and circuit breaker as supporting patterns that make service-to-service calls resilient.
| Pattern | Use it when | Failure if skipped |
| Timeout | Every call between services | One slow service holds up every caller |
| Retry | A failure is likely to be temporary | A brief network fault becomes a visible error |
| Circuit breaker | A service keeps failing | Callers keep hitting a broken service and add to its load |
| Bulkhead | One workload could use up shared resources | A spike in one feature takes down unrelated features |
Our microservices best practices guide ranks these habits by when a team needs each one.
Cross-cutting and microservices security patterns
The sidecar pattern moves shared jobs such as logging and networking into a helper that runs next to each service. Microsoft describes it as attaching helper functionality to a service without embedding it in the service’s code, so the service keeps one job. In TekRevol’s reading, a service mesh applies the same idea across every service.
Security patterns follow the same rule of keeping security out of business code. A gateway can take over authentication and rate limiting, which Microsoft calls gateway offloading, and, in TekRevol’s reading, an access token carries the caller’s identity to the services behind it. In TekRevol’s judgment, authorization stays inside each service, because the service that owns the data knows what a caller may do with it.
| Pattern | Use it when | Trade-off |
| Sidecar | Many services need the same helper, such as logging | One more process to run next to every service |
| Gateway offloading | Authentication or rate limiting should not repeat in each service | The gateway becomes a critical point to protect and scale |
| Access token | Services need to know who the caller is | Each service must check the token and handle expiry |
Applying the selector to a grocery checkout
A grocery checkout needs four patterns. The example is TekRevol’s illustration and uses no real numbers.
| Checkout step | Problem | Pattern applied |
| The shopper opens the store on a phone and on a website | Each client needs a different response | Backend for frontend |
| The order is confirmed only after the card is charged | Orders and payments own separate data | Saga |
| The payment service responds slowly | The orders service would wait and time out | Circuit breaker, after a timeout |
| Delivery slots and notifications must react to a confirmed order | The orders service should not call each one | Publisher-subscriber |
The shopper checks out, and the orders service asks payments to charge the card. If the payment service is slow, the circuit breaker stops the orders service from waiting, and the shopper is asked to retry, while other shoppers keep browsing. Once the charge succeeds, orders publishes one event, and the delivery and notification services react on their own.
Every other pattern in this guide stays on the shelf until a problem calls for it.
When design patterns are overkill
Skip a pattern until the problem it solves has appeared. In TekRevol’s judgment, a team with one deployable application or a modular monolith has no use for a saga or a sidecar, because those patterns fix problems that only exist between services. TekRevol’s comparison of monolithic vs microservices helps decide whether services are worth it at all.
Each pattern adds parts to build and run. Add one when you can name the failure it prevents, and drop it when the system no longer has that problem.
Choosing patterns for a real system?
If you want a second opinion on which patterns your system needs, start with the problem that worries you most, such as data consistency across two services.
TekRevol, a software development company, plans architecture, workflows, database schema, and API structure in the design stage of its custom software development process. TekRevol’s cloud application development team builds containerized microservices on Docker and Kubernetes.
Bring one problem and the services it touches. Pick the pattern that fixes today’s problem. Get a Free Consultation.
