Microservices architecture best practices for 2027
It starts with one deployment. A team pushes a routine change, and forty minutes later three other teams are in a war room trying to figure out why checkout is timing out.
No one touched the checkout. Someone just touched the service checkout just so happens to call, twice removed, and the failure cascaded through a dependency chain that exists only in production.
That is the moment most engineering leaders start taking software architecture seriously, and not the way conference talks describe it.
This guide skips the diagram-level pitch. If you already know what a microservice is, you do not need another article explaining it. We offer microservices architecture best practices that hold up once real services are running in production, under real load, owned by real teams that do not always agree. They are organized around six pillars that separate systems which stay maintainable from ones that quietly turn into a distributed monolith:
Service boundaries
Data ownership
Communication design
Observability
Security
Deployment
What "best practice" means here
Every one of the best practices for microservice architecture below trades one kind of complexity for another.
A monolith's complexity is internal: a large, tangled codebase where no one fully understands the blast radius of a change. A microservices architecture's complexity is external: a distributed system with network calls, partial failures, and eventual consistency standing in for what used to be a function call.
That trade pays off once your organization has actually outgrown the coordination costs of a single shared codebase.
A practice earns its place in this guide because it makes that trade defensible. That standard rules out some of what passes for generic "microservices best practices" advice elsewhere.
6 best practices of microservices architecture
1. Design service boundaries around what actually changes together
Most microservices architecture failures trace back to this decision, made too early and based on the wrong criteria.
1.1 Use domain-driven design to find the boundary
The org chart is not a domain model. Splitting services by team headcount or by whichever team shouted loudest in the planning meeting creates boundaries that misalign with how the business actually works.
Misaligned boundaries are expensive to fix later, because every consumer has to change, too.
Domain-driven design gives you a better starting point: bounded contexts. A bounded context is a boundary within which a term means exactly one thing. "Customer" in billing is not "customer" in support, and forcing them to share a definition produces a service that tries to serve two masters and satisfies neither.
Map the bounded contexts first. Let the services follow.
Uber's engineering team documented this the hard way. Their original microservices split grew past a few thousand services with unclear ownership boundaries between them.
Their fix was to formally group services into business domains, with clear gateways at the domain edge rather than ad hoc calls between any two services that happened to need each other.
The lesson generalizes past Uber's scale: domain boundaries need to be a deliberate design decision, revisited on purpose [1].
1.2 Keep the single-responsibility principle, but at the service level
Single responsibility does not mean small. It means one reason to change.
A service that owns pricing logic, and only pricing logic, can change its rules without touching anything else. A service that owns "pricing and also some inventory checks because it was convenient at the time" now has two reasons to change, and every deploy risks breaking the one it did not intend to touch.
Chris Richardson's "dark energy, dark matter" framing is the clearest existing explanation of why this balance is hard: some forces pull services apart, others pull them back together.
| Forces pulling services apart | Forces pulling services back together |
|---|---|
| Simpler, more focused components | Simpler interactions between fewer moving parts |
| Team autonomy and faster deploys | Fewer costly network round-trips |
| Freedom to pick different tech per service | One ACID transaction over a distributed saga |
| Scaling or securing pieces independently | Less coupling, at runtime and at design time |
Richardson describes them as "the forces that encourage and resist decomposition of a system into smaller components" [2]. Every boundary decision is negotiated between the two. It is rarely a one-time answer.
2. Own your data. Don't share it.
If service boundaries are the most common early mistake, sharing a database is the one that goes unnoticed the longest, until it hurts.
2.1 Database-per-service, and why sharing one is the most common early mistake
A shared database looks efficient at first. It is the fastest way to build version one, and the reason version two is hard to change.
Once two services read and write the same tables, they are coupled at the schema level, whether anyone admits it or not. A column rename in service A breaks service B's queries, and now a "simple" migration needs coordinated deploys across teams that do not report to the same manager.
Database-per-service fixes this by construction. Each service owns its schema and its storage technology, and nothing outside that service touches its data directly.
Microsoft's Azure Architecture Center puts it plainly: each service should own its data and schema, because that ownership "reduces cross-service dependencies and allows services to evolve independently" [3].
The cost is real: you give up cross-service joins and transactions that span services. Most teams find that the cost is smaller than the alternative, once they have lived through one shared-database migration.
2.2 Contracts over internal models (DTOs, API versioning)
A service's internal data model is an implementation detail. What it exposes to other services is a contract, and it needs the same discipline as a public API, because in practice, it is one.
Use data transfer objects separate from your internal entities, so a schema change within the service does not automatically become a breaking change for everyone downstream. Version the contract explicitly, so a consumer can tell from the version alone whether a change is safe to ignore.
2.3 When eventual consistency beats a synchronous transaction
Without a shared database, you also lose the ability to share transactions. A checkout that used to update inventory and orders in a single transaction now has to coordinate with two services, each of which can fail mid-operation independently.
Eventual consistency is the answer for most of these cases, because the alternative, distributed two-phase commits, is slower, more fragile, and harder to reason about under failure.
Design for the state where inventory and orders briefly disagree. Define how long "briefly" may last. Build the reconciliation path instead of pretending the inconsistency window does not exist:
A saga that walks back a partial failure step by step
An event that the downstream service reacts to once it arrives
A retry with backoff for cases that just need another attempt
The Azure Architecture Center is direct on this: it is "unlikely that the complete data change could be considered an atomic, consistent, isolated, and durable transaction," so the right move is to "embrace eventual consistency where possible" rather than architect around avoiding it entirely.
3. Design communication for the failure case
A monolith's function calls fail in one way: they throw. A network call between services fails in a dozen ways, and most microservices architecture incidents trace back to a failure mode no one designed for.
3.1 What an API gateway should and shouldn't own
An API gateway is the front door: routing, authentication at the edge, rate limiting, and request aggregation for clients that need data from several services in one round trip.
What it should not own is domain logic. The moment a gateway starts making business decisions, "should this discount apply," "is this user eligible," it becomes a second copy of logic that now has to stay in sync with the service that owns the real answer.
Gateways have a way of becoming the place logic goes to get forgotten. Keep the gateway thin: route, authenticate, aggregate. Let the services decide.
3.2 Choosing sync vs. async: REST/gRPC vs. message queues
Synchronous calls (REST, gRPC) are simpler to reason about and appropriate when the caller genuinely needs an immediate answer to proceed. They also couple the caller's availability to the callee's: if the downstream service is slow or down, the caller is stuck waiting, and that wait can cascade upstream.
Asynchronous communication through message queues or event streams breaks that coupling. The caller publishes an event and moves on; the consumer processes it when it can.
This is the right default for anything that does not need an immediate response: notifications, downstream updates, anything where "eventually" is an acceptable answer. The tradeoff is that async systems are harder to trace and debug, which is exactly why the observability practices below are not optional once you adopt them.
3.3 Circuit breakers, retries, timeouts, bulkheads: what each one actually prevents
These four patterns solve four different failure modes, and conflating them is how teams end up with resilience code that does not actually protect anything.
| Pattern | What it prevents | What happens without it |
|---|---|---|
| Timeout | A caller waiting forever for a response that will never come | Threads pile up waiting, and the caller runs out of capacity too |
| Retry | A transient failure (a dropped packet, a momentary blip) from becoming a hard failure | A one-off glitch turns into an unnecessary error surfaced to the user |
| Circuit breaker | A struggling downstream service from being hammered with more requests while it is trying to recover | The retries meant to help make the outage worse, and the failure spreads upstream |
| Bulkhead | One overloaded dependency from consuming all of a service's resources | A failure in one integration takes down every other function the service performs |
A circuit breaker specifically watches for a failure rate crossing a threshold, then "opens" and stops sending requests to the failing service for a cooldown period, giving it room to recover instead of adding load to a system that is already struggling.
Netflix popularized the pattern at scale with Hystrix, precisely because a single degraded dependency could take down services unrelated to the original problem.
3.4 Idempotency: why retries are dangerous without it
Retries and idempotency are a package deal. If a payment service retries a charge because the first response timed out, but the first charge actually succeeded, the customer is charged twice unless the operation is designed to be idempotent: the same request sent twice produces the same result as sending it once.
Use idempotency keys on anything that mutates state and might get retried. Without this, every resilience pattern above becomes a way to create new bugs rather than prevent them.
4. Build observability before you need it
The first production incident in a microservices architecture makes the case for observability better than any pitch deck. A single request that used to touch one process now touches six, and when it fails, "where" is the first question and often the hardest one to answer.
4.1 Centralized logging and distributed tracing
Logs scattered across a dozen services, each with its own format, are close to useless during an incident. Centralized logging with a consistent structure, so a single query can pull every log line related to one request, is table stakes.
Distributed tracing goes further. It attaches a trace ID to a request at the edge and propagates it through every service the request touches, so you can see the entire path, including where the time actually went.
Without tracing, "which of these six services is slow?" is a guessing game. With it, it is a query.
4.2 Health checks and SLOs
"Is the service up?" is the wrong question. Answering it is not the same as answering "is the service doing its job." A service can be up and still failing every request that matters. Health checks should distinguish between two different things:
Liveness: is the process running at all
Readiness: can it actually serve traffic right now
Service level objectives push this further by defining what "working" means in terms the business cares about: 99.9% of requests under 300ms, for example, rather than a binary up-or-down. This is also where microservices observability earns its keep: an SLO you cannot measure is a slogan, not a target.
5. Treat security as infrastructure
Most microservices architecture security best practices guides treat security as a final section: a list of things to bolt on before launch.
That ordering is itself the problem. Security decisions made after the architecture is set are almost always more expensive than the same decisions made during design.
5.1 Zero trust between services
The old model assumed the network perimeter was the security boundary: firewall at the edge, trust everything inside.
In a microservices architecture, "inside" encompasses dozens of services with different owners, deployment cadences, and vulnerabilities. A single compromised service should not get a free pass to every other service it can reach.
Zero trust flips the assumption: every service-to-service call gets authenticated and encrypted, regardless of which network it is on.
Mutual TLS (mTLS) is the common mechanism, where both sides of a connection verify each other's identity via certificates. A service mesh (Istio, Linkerd) can enforce this at the infrastructure layer, so individual services do not each have to implement mTLS themselves.
5.2 Where authentication should live: gateway vs. per-service
Authenticate identity once, at the edge, typically via the API gateway or an identity provider issuing a token (OAuth 2.0, OIDC). Do not make every service re-implement login.
Authorization is different. Whether this authenticated identity is allowed to do this specific thing needs to happen closer to the resource, often in the service itself, because the gateway usually does not have the domain context to make that call correctly.
Authenticate centrally. Authorize locally, informed by a centrally issued identity.
5.3 Secrets management and dependency scanning (the part most best-practices lists skip entirely)
Database credentials, API keys, and certificates hardcoded in config files or environment variables checked into a repository are a routine cause of breaches.
A microservices architecture increases the number of services that need secrets, which increases the number of places a leak can occur. Use a dedicated secrets manager, such as Vault, AWS Secrets Manager, or Azure Key Vault, with rotation, not static values passed around by hand.
Dependency scanning matters more here too, not less. Dozens of services usually means dozens of independent dependency trees, each one a potential entry point.
A vulnerability in a shared library does not announce itself once. It announces itself once per service that has not patched yet, and without automated scanning across all of them, it goes unnoticed until exploited.
6. Containerize and automate deployment
This is where most of the best practices for microservices development pay off or fall apart, because deployment is the practice you run the most often.
6.1 Containers plus orchestration, and what orchestration actually buys you
Containers solve "it works on my machine" by packaging a service with its dependencies into a portable, consistent unit.
Orchestration (Kubernetes is the default choice for most teams now) handles what containers alone cannot: scheduling, scaling, health-based restarts, and service discovery across dozens of services, each potentially running multiple instances, so no one is babysitting them by hand.
6.2 Independent CI/CD per service
A shared deployment pipeline across every service defeats the point of microservices architecture before it starts.
If deploying service A requires the same pipeline run, the same approval, the same release train as nineteen other services, you have rebuilt a monolith's release cadence with a distributed system's operational overhead. That is the worst of both.
Each service needs its own:
Tests
Build
Deploy
Release schedule, decoupled from every other service's release cycle
That is what "independently deployable" actually means in practice, and it is the single biggest reason teams adopt microservices in the first place. Brights has covered the full pipeline setup in more detail in our guide to independent CI/CD pipelines.
6.3 Backward-compatible versioning (Postel's Law, semantic versioning)
Independent deployment only works if services can be upgraded out of order without breaking each other. That requires backward compatibility as a discipline.
Postel's Law ("be conservative in what you send, liberal in what you accept") is the right instinct here: a service should tolerate fields it does not recognize rather than rejecting the whole request, and it should not remove a field or change its meaning without a deprecation window.
Semantic versioning on your APIs, where a breaking change bumps the major version and everything else does not, gives consumers a reliable signal for when they actually need to update code, versus when they can ignore a release entirely.
Structure teams the way you structure services
This is the section most best-practices guides skip, and skipping it is why a technically well-designed microservices architecture can still feel slow to work with.
Conway's Law is a real constraint, not a joke: your system's structure will mirror your organization's communication structure, whether you plan for that or not.
If three teams have to coordinate to ship one feature, because the service boundaries cut across how those teams actually work together, the architecture is fighting the org chart. The org chart usually wins.
The fix is aligning team boundaries to service boundaries on purpose, so that most changes stay within one team's remit.
Two more team-structure practices matter just as much:
Full lifecycle ownership. The team that builds a service also runs it: on call for it, accountable for its incidents. Separating "who builds it" from "who gets paged for it" removes the feedback loop that makes engineers write more reliable code. A team that wakes up for its own outages designs differently than one that hands off the pager.
Standardize the boring, invisible layer. Logging format, health-check shape, how services expose metrics, without forcing teams to share actual code or deployment schedules. This is the part most best-practices guides omit: cross-team governance exists so that when something breaks at 2am, whoever is debugging it does not first have to relearn each team's private conventions before they can start.
Anti-patterns worth naming
Most of these show up gradually, which is why they are dangerous. No one decides to build a distributed monolith. It accumulates one shortcut at a time.
Shared libraries that force synchronized deployments. A common library used by every service sounds efficient until updating it means coordinating a release across every team that consumes it. That coordination cost is exactly what independent services were supposed to remove.
Database entities used as events, exposing internal schema. Publishing your database row as an event couples every consumer to your internal schema. Change a column, and you have silently broken services you may not even know are listening.
A "distributed monolith." Services that are technically separate processes but cannot ship independently, because of shared databases, shared libraries, or synchronous call chains that require every service in the chain to deploy together. You get the operational overhead of microservices architecture with none of the benefit.
Security logic embedded in individual services instead of delegated to the gateway or mesh. Every service reimplementing its own auth check, inconsistently, is both a security risk and a maintenance burden. Centralize what should be centralized.
Microsoft's Azure Architecture Center names a related version of this directly: sharing libraries or dependencies between services "creates tight coupling, which makes changes risky and widespread," and exposing services directly to consumers without a gateway "results in tight coupling, scalability problems, and security risks."
Both are microservices anti-patterns that look like reasonable shortcuts in month one, and become the reason a "microservices" system still needs a coordinated quarterly release by month eighteen.
When microservices are the wrong call
A guide that only sells microservices reads as vendor content, not advice. Here is the honest version: microservices architecture is usually the wrong call when
the team is small enough that the coordination problem does not exist yet
domain boundaries are still unclear
traffic does not yet justify independent scaling
In any of these cases, a monolith, or a modular monolith that keeps clear internal boundaries without the network overhead, usually ships faster and costs less to run.
Amazon's own Prime Video engineering team lived this in reverse. Their audio and video quality monitoring service was built as a distributed, serverless architecture with independently scaled microservices, and it hit a wall.
The distributed approach could only support a fraction of the expected load, and the cost of moving data between services, S3 storage, orchestration overhead, dominated the bill.
They consolidated the components into a single monolithic process running on containers, and cut infrastructure costs by 90%.
In the words of the engineer who led the change: "We realized that a distributed approach wasn't bringing a lot of benefits in our specific use case, so we packed all of the components into a single process". [4]
That is an argument against applying microservices architecture by default to a workload where the coordination benefits never outweigh the distributed-systems tax.
The real difference between microservices vs. monolithic architecture comes down to whether the coordination cost of one shared codebase is actually the bottleneck you are trying to solve, or whether you are solving a scaling problem that does not exist yet with an architecture built to solve it.
Wrapping up
The microservices architecture best practices above come down to one narrower question: can one team change one service, ship it, and know that nothing outside their remit broke, without a meeting to coordinate it?
Service boundaries, data ownership, resilient communication, observability, security, and independent deployment all exist to make that answer yes more often. Get that right, and the diagram stops mattering nearly as much as whether the people who own it can move.
Brights has spent the past several years inside exactly this kind of decomposition work, mostly for teams migrating off aging monoliths under real production load.
That is a different problem than most guides account for: you are redrawing boundaries around a system that already has customers, and every wrong cut has a blast radius.
If your team is weighing whether to split a service or trying to untangle one that already went too far in the wrong direction, that is the specific problem our delivery teams in Warsaw and Kyiv solve for enterprise and scale-up clients on a regular basis.
References
Uber Engineering, "Introducing Domain-Oriented Microservice Architecture," [1]
Chris Richardson, "About dark energy and dark matter: forces that shape an architecture," [2]
Microsoft Learn, "Microservices architecture style," Azure Architecture Center [3]
InfoQ, "Prime Video Switched from Serverless to EC2 and ECS to Save Costs," [4]
FAQ.
Usually not yet. Early on, domain boundaries are still shifting, and splitting services before you know where the real seams are means redrawing boundaries and rewriting integration code at the same time. A modular monolith, with clear internal boundaries, gets you most of the organizational benefit without the distributed-systems overhead.
