Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

StyleChapter II · Styles & patterns · Building block 3 of 8

Microservices

Microservices are technically defined services with their own provision and operational responsibility. Their independence also generates networking and coordination effort.

By Michael Meierhoff · Meierhoff Systems

  1. Own serviceOwn provision, data and responsibility.
  2. ConditionsData, contract and operation must stand.
  3. Distributed MonolithBuilt separately, but further dependent.

Context

Why this is important

An own service only makes itself independent if team, data, contracts and operations are involved; otherwise, a distributed monolith is created. The Fallacies of Distributed Computing begin with the misconception that the network is reliable. Strangler Fig triggers an ability stepwise. For business boundaries within an application, see Modular Monolith.

This building block explains independent service boundaries. For business boundaries within an application, see Modular Monolith.

At a glance · Independent services with their own database

Each service runs within its own framework with its own database and is only reached via network calls, shown in dashed lines.
Shop example · Readiness test

Does the shipment carry its own service?

Variant: The shop separates the shipment as a separate service, because a separate team publishes and scales it independently. The remaining six modules remain in the modular monolith; the payment provider remains external.

This is how you read the picture

  1. Own service The judgment “own service carries” appears when benefits and all requirements are ticked.
  2. Conditions The group ‘Requirements’; dots not marked with a cross appear under ‘Absent:’.
  3. Distributed Monolith The judgment “Risk Distributed Monolith” in case of benefit without complete prerequisites.
UseWhat your own service brings to the shop
ConditionsWhat to vote for

Risk Distributed MonolithThe benefits are there, but not all the prerequisites stand. The service would be separate, but would remain dependent and expensive in operation.

It is missing: Own dispatch data, Fixed-default contract, Operation from a single source

Check which applies to shipping; the verdict changes immediately, based on Fowler’s Microservice Prerequisites.

Benefits & limitations

Helps if:

  • Capabilities requiring independent releases gain separate change and release paths through their own service contracts.
  • Different load profiles can be served by allocating resources to the service that needs them.
  • A team that owns data, contracts, monitoring and recovery can sustain an independent service boundary.

Boundaries

  • An order via two services requires coordination and visible intermediate states because there is no longer a joint transaction; see Saga.
  • Operating an independent service requires readiness to monitor it and restore it after failures.
  • Shared tables or long synchronous call chains lead to a Distributed Monolith, with distribution costs but little autonomy.

In practice

  1. Define a service around a business capability and assign ownership of its data, contract and operations. Its boundary should let one team develop and recover it independently.
  2. Define the timeout, result and unknown outcome for each operation. A caller needs a way to resolve status when no response arrives; see Timeout and Partial Failures.
  3. Assess release autonomy, load distribution and operational effort together. Examine Distributed Monolith when coupling is tight; Data Ownership describes the associated dependencies.
Read the detailed explanation

A microservice owns a business capability, its contract and the state it has authority to change. Other services interact with it over a network or through published events. Teams can develop, deploy and scale individual services independently.

Process boundaries introduce latency, versioning, failures, observability and recovery requirements. A timeout does not establish an operation's outcome, so contracts must make ownership and failure semantics explicit. Independence covers development and operations, not merely a separate process.

Bounded Context helps define domain boundaries; Distributed Monolith explains when network boundaries still require coordinated releases.

Self-contained Systems (SCS) are a related approach: each business area is an independent web application with its own user interface and data. The pattern is particularly common in German-speaking countries.

Calling Shipping over a network introduces the assumptions described in Fallacies of Distributed Computing, such as assuming the network is reliable. Strangler Fig supports extracting Shipping gradually rather than rewriting it all at once.

An independent service needs an accountable team with decision-making authority and ownership of data and operations; a separate process alone does not create that autonomy.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Which judgment shows the picture in the starting state, and what is missing?

    View the solution with justification

    Risk Distributed Monolith: Team and release clock are ticked, but own shipping data, fail-safe contract and operation from a single source are missing.

  2. ApplyingTransferred to a new situation

    The shipment receives its own data, but the operation is not yet regulated. What does the verdict show?

    View the solution with justification

    Furthermore, Risk Distributed Monolith. “It is missing” only mentions a fail-safe contract and operation from a single source.

  3. EvaluateWeighing an alternative

    All six criteria are met. Should the shipment be rewritten as a service immediately?

    View the solution with justification

    No, not necessarily. A complete replacement bundles risk and leaves no way back. Better Strangler FIG.: detach stepwise, measure, switch back as required. For this, the transition takes longer.

Explore further

These optional deepenings complement the learning goal of this page.

Peer-to-peer

Peer-to-Peer assigns roles so that participants can both provide and consume services, depending on the operation. In a hypothetical shop extension, equal merchant nodes could publish, query and forward stock offers. This differs from a central shop platform with distinct client and server roles. The merchant network needs rules for identity, conflict resolution, reachability and message delivery. This style suits a demonstrated business need for decentralised collaboration.

For testingCompare the central shop platform with a hypothetical marketplace of equal merchant nodes. Check that each node must publish and query offers, and clarify identity, conflict resolution, accessibility, and delivery before choosing peer-to-peer as a form of network.

Further building blocks

Styles & patternsModular monolithA modular monolith separates domains within a single application deployed as one unit.Opening CommunicationSynchronous communicationSynchronous communication connects request and response; the caller waits for the result or until its timeout expires.Opening DataData ownershipData ownership defines which building block is responsible for data and its domain rules.Opening OperationsObservabilityObservability combines signals that let you inspect a system's internal state.Opening

References

Continue on the learning path

Next in Styles & patterns: Hexagonal architecture.

8 Building blocks

Continue withHexagonal architecture