Microservices architecture divides an application into services that can be developed, deployed, and operated with meaningful independence. This guide explains what that independence requires, how services communicate and own data, and when the added distributed-system complexity is worth accepting.
What Is Microservices Architecture?
A microservices application consists of independently deployable services organized around business capabilities, such as ordering or notifications. Each service exposes an explicit interface and owns its behavior and data responsibilities. The approach can enable independent scaling and team delivery, but introduces network failures, consistency challenges, and a larger operational burden.
What makes a service a microservice?
Small size alone does not establish a microservices architecture. A collection of tiny programs that must always be changed and released together behaves more like a distributed monolith. The important properties are clear responsibility, stable interfaces, ownership, and the ability to deploy without coordinating every other component.
Microsoft's architecture guidance describes microservices as services built around business capabilities and highlights independent deployment alongside challenges such as complexity and data consistency (Microsoft architecture guidance). Those characteristics matter more than a particular programming language or container platform.
A service might handle order submission, inventory availability, or customer notifications. It should expose the operations others need while hiding implementation details they should not depend on. Directly reading another service's internal database tables undermines that boundary because internal schema changes become cross-service changes.
There is no universal line-count or team-size threshold. A service should be small enough to understand and own, but broad enough to contain a coherent responsibility. Splitting every class or database table into a separate network service usually creates communication overhead without useful independence.
Technology flexibility is possible but not free. Different services can use different languages or databases, yet each addition increases the number of tools, deployment paths, and operational skills the organization must maintain. Standardization often remains valuable even in a decentralized architecture.
Compare microservices with a modular monolith
A monolith is deployed as one application unit; it need not be poorly structured or tightly coupled internally. A modular monolith can have strong domain boundaries, separate interfaces, and disciplined ownership while keeping calls in-process.
Microservices move some of those boundaries across networks. That creates independent deployment opportunities, but also turns ordinary function calls into operations that can be delayed, fail, or return an ambiguous result.
| Dimension | Modular monolith | Microservices |
|---|---|---|
| Deployment | One main release unit | Multiple independent release units |
| Calls | Often in-process | Network or messaging boundaries |
| Transactions | Often easier within one data system | Cross-service coordination needed |
| Scaling | Usually scale the application unit | Scale selected services separately |
| Debugging | Fewer runtime boundaries | Distributed correlation required |
| Team autonomy | Supported through internal discipline | Supported through ownership and contracts |
| Operations | Usually fewer moving parts | More identities, releases, and dependencies |
Neither model determines whether an application uses one database, multiple databases, or containers. A monolith can use several stores, and multiple services can share physical database infrastructure while retaining strict logical ownership. The important question is whether shared implementation details prevent independent change.
For a small team with uncertain business boundaries, a modular monolith is often a practical starting point. It allows the domain model to evolve before early guesses become remote interfaces that are harder to change.
How requests and events move through services
Services commonly communicate through synchronous APIs or asynchronous messaging. A synchronous request expects a response during the current interaction. An asynchronous message allows another component to act later, with different expectations about timing and acknowledgement.
Suppose an order API validates a request and asks an inventory service whether stock can be reserved. That direct call creates a runtime dependency: if inventory is slow or unavailable, ordering needs a defined response. Timeouts, bounded retries, and degraded behavior become part of the design.
Alternatively, an order service may publish an event after recording an order, and a notification service later sends an email. The user-facing request need not wait for email delivery. But the system must handle delayed messages, duplicates, and failures in the consumer.
Events should describe meaningful facts, such as an order being accepted, rather than expose every internal database update. Consumers should rely on a documented contract. Versioning and compatibility rules help producers evolve without breaking all subscribers at once.
Retries deserve particular care. If a payment request times out, the caller may not know whether the payment succeeded. Retrying blindly can produce duplicate side effects. Idempotency keys or equivalent deduplication mechanisms help make repeated requests safe under a defined scope and retention policy.
Avoid long chains of synchronous dependencies where possible. A request touching many services inherits more opportunities for latency and failure. Service boundaries should reflect coherent responsibilities, not merely distribute every step of a process across another machine.
Data ownership changes the transaction model
A service should control access to the data needed for its responsibility. Other services use its interface or maintained projections rather than silently updating its internal records. This makes local change easier but complicates operations spanning multiple owners.
Consider a hypothetical checkout involving an order service, inventory service, and payment service. Each can complete a local update, but the overall workflow can fail partway through. You need explicit states and recovery actions rather than assuming a single database transaction covers everything.
A saga-style workflow coordinates local steps and compensating actions. If inventory is reserved but payment fails, the process might release the reservation and mark the order unsuccessful. Compensation is a business operation, not necessarily a literal reversal of every technical action.
Microsoft's compensating-transaction pattern explains that recovery may require application-specific logic and may itself fail or need retries (compensating transaction guidance). Sending a cancellation email, for example, cannot erase a previously delivered confirmation email from a user's inbox.
Define what users see during intermediate states. “Processing,” “awaiting payment,” and “confirmed” may be meaningful distinctions rather than implementation details. Decide how long a workflow can remain pending and who resolves cases that automated recovery cannot complete.
For cross-service reporting, use purpose-built read models or data pipelines where justified. Recognize that these copies may lag. Identify which service is authoritative and whether the reporting use case tolerates delay before promising immediate consistency.
Benefits depend on the boundaries and operating model
Independent scaling can be useful when demand is uneven. A search service might need more capacity than account settings, allowing targeted expansion rather than scaling the entire application. Whether that saves resources depends on workload, infrastructure overhead, and data dependencies.
Independent deployment can help teams release changes without coordinating every application feature. That requires backward-compatible contracts and tests that cover integration behavior. If every release requires a shared ceremony, the promised autonomy has not materialized.
Fault isolation is also conditional. One failed service need not stop everything if callers have timeouts, sensible fallbacks, and adequate resource isolation. Without those controls, a failing dependency can consume connections or workers and spread disruption across the system.
Organizational ownership matters as much as technology. Teams need responsibility for design, deployment, monitoring, and incident response. A service without an available owner becomes a shared operational risk, regardless of how neatly its code is packaged.
The costs include more deployments, credentials, dashboards, network policies, compatibility checks, and on-call knowledge. Microservices can trade some coordination costs for operational costs. The architecture is worthwhile when the new trade-off solves a real organizational or workload constraint.
Adopt microservices selectively and prove the value
Why: A wholesale rewrite creates many new boundaries before their value is established. A smaller extraction lets you learn from an actual production requirement.
How: First improve modularity inside the existing application. Identify a bounded capability with a clear owner and a concrete reason for separation, such as an independent scaling requirement or repeated deployment contention.
Define its API, data ownership, failure behavior, and observability before extracting it. Keep the initial interface narrow. Avoid choosing a capability that requires constant back-and-forth access to the monolith's internal state, since that coupling will follow it across the network.
For a hypothetical commerce application, notification delivery may be a suitable extraction if delayed delivery is acceptable and the service consumes clear business events. It is not automatically the right choice: if notification content requires synchronous calls to many internal components, the boundary may need redesign first.
Establish deployment automation, service identity, secrets management, and logs with correlation identifiers. Add metrics for error rates, latency, saturation, and business outcomes. Distributed tracing can help follow requests across boundaries, but useful instrumentation requires consistent context propagation.
Containers and orchestration can help manage service instances, yet neither is mandatory for the architectural pattern. Choose infrastructure appropriate to the team's capabilities. Evaluate whether the extracted service actually improved release autonomy or resource management before extracting another.
Questions About Microservices Architecture
Can services share a physical database server?
They can, provided data ownership, permissions, and operational dependencies are understood. Sharing tables and allowing unrestricted cross-service updates creates stronger coupling than sharing infrastructure. Physical separation alone also does not guarantee logical independence.
Do microservices require Kubernetes?
No. Services can run on managed platforms, virtual machines, containers, or other hosting arrangements. Kubernetes is an orchestration option, not the defining feature of microservices, and its operating cost should be justified separately.
How do teams test an application with many services?
Combine local component tests with contract tests and focused integration tests. Keep a smaller set of critical end-to-end checks. Testing everything only through a shared full-system environment makes failures harder to localize and can recreate release coordination bottlenecks.
When should a team avoid microservices?
Be cautious when the team is small, domain boundaries are unstable, deployment automation is weak, or most features require coordinated changes everywhere. Strengthening a modular monolith may deliver more value with fewer operational risks.
Use Services Only When Boundaries Help
Microservices are a way to create independent business and deployment boundaries, not a default badge of modern software. Adopt them where ownership, scaling, or delivery needs justify network and operational complexity, and keep a modular monolith when it better fits the problem.
Next steps: Build the delivery foundation with the CI/CD checklist, examine storage trade-offs in the SQL vs. NoSQL guide, or visit Software Development.
Sources
- Microsoft — Microservices architecture style
- Microsoft — Compensating Transaction pattern
This guide is general education, not professional advice.