Types of Microservices: Seven Archetypes That Shape System Design

What Are Service Archetypes?

When you decompose a system into microservices, the services you end up with are not random. Across many different teams and industries, the same shapes appear again and again — services that own critical business state, services that coordinate workflows, services that sit at the system boundary. These recurring shapes are archetypes.

This article describes seven of them. They cover the vast majority of services you will encounter or build. But they are not a fixed taxonomy. Some teams find they need variants not described here — notification delivery services and internal composition services are two that come up regularly. The seven archetypes are a starting point, not a ceiling. If your system produces a shape that does not fit neatly into one of them, that is fine. Name it, understand the forces driving it, and build it accordingly.

Archetypes Emerge, They Are Not Chosen

The best way to identify a service archetype is to look at what forces created it. Do not start with a menu of types and try to pick the right ones. Start with the pressures in your system — data ownership, change frequency, scaling, reliability, business capability. The pressures will point you to the archetype. The archetype will tell you how to build.

Archetypes emerge from the forces acting on your system: data ownership pressures, change frequency differences, scaling requirements, reliability needs, and domain boundaries. When a force becomes strong enough to justify a network boundary, the shape of that boundary is not arbitrary. The pressure dictates the shape. The shape is the archetype.

Your job is to recognise which archetype is emerging from your specific pressures, then build that service the way the archetype demands. A Core Domain service built like an Edge service will fail. A Supporting service given the change controls of a Core Domain service will frustrate everyone.

A service rarely starts as what it becomes. A Core Domain service often begins as a Supporting service before the business realises it owns critical state. A Read Model often starts as a reporting query inside a monolith before load pressure demands extraction. The archetype is not chosen at birth — it is revealed as forces intensify.

Forces map to archetypes consistently:

1. Data and Domain forces produce Core Domain services.
2. Domain and Change forces produce Supporting services.
3. Load and Reliability forces produce Edge services.
4. Load and Data forces produce Read Model services.
5. Reliability and Domain forces produce Workflow services.
6. Load and Change forces produce Infrastructure services.
7. Reliability and Domain forces produce Anti-Corruption services.

Archetype One: Core Domain Services

Core Domain services own the authoritative business state — the source of truth your business cannot operate without. Orders. Payments. Accounts. Inventory. Get these wrong and nothing else matters.

These services emerge from Data and Domain forces. The data they own cannot be safely shared across service boundaries. The domain boundary is clear and stable. Reliability requirements are the highest in the system, data loss is catastrophic, and change frequency is intentionally low. A Core Domain service that deploys every week is either not a Core Domain service, or you have a larger problem than architecture.

Consider an Order service in an e-commerce platform. It owns the canonical record of every order — status, line items, timestamps, and payment references. Every other service that needs order data reads from it or reacts to its events. Nothing writes to an order except the Order service itself.

Keep APIs simple and stable.

Prefer synchronous communication for immediate consistency but avoid deep call chains — every outgoing synchronous dependency is a failure dependency you are accepting. The right pattern is for Core Domain services to emit events that others consume asynchronously, rather than being the downstream target of synchronous calls from orchestrating services. The Order service emits an OrderPlaced event. Downstream services react to it. The Order service does not call them.

Archetype Two: Supporting Domain Services

Supporting Domain services enable core workflows without being system-critical. The business does not stop if they are unavailable for a few minutes. Examples include Shipping, Invoicing, Loyalty, and Subscription management.

These services emerge from Domain and Change forces. The domain boundary is real, but the more important driver is change frequency — Supporting services change faster than Core Domain services. Shipping carriers update APIs. Loyalty rules change with campaigns. Extracting these services lets them change at their own pace without touching core transaction flows.

A Loyalty service is a good example. When an order is placed, the Loyalty service listens for the OrderPlaced event and accrues points in the background. The customer sees their order confirmation immediately. The points appear shortly after. If the Loyalty service is briefly unavailable, the system queues the event and processes it when the service recovers — no order is lost, no customer is blocked.

Design for this graceful degradation explicitly. Be clear about which failures are tolerable — losing a loyalty accrual may be acceptable with a reconciliation job — and which are not — losing an invoice for a completed payment is a different matter.Build idempotent consumers so duplicates do not cause harm. Build dead-letter queues so failures do not block the queue. Then even when processing is delayed, the system stays safe.

Archetype Three: Edge and Interaction Services

Edge services are the first point of contact for external clients — mobile applications, browsers, third-party integrations. Examples include API Gateways, Backend-for-Frontend (BFF) services, and Authentication services.

These services emerge from Load and Reliability forces. They handle high request volumes and protect internal services from malformed requests, excessive traffic, and authentication failures. Edge services are stateless. They do not own data. They validate requests, authenticate callers, route traffic, enforce rate limits, and sometimes aggregate responses from downstream services.

A mobile BFF is a clear example. The iOS application needs a single endpoint that returns everything required to render the order summary screen — order details, loyalty balance, and estimated delivery date. The BFF calls three downstream services, composes the response, and returns it. It owns none of that data and applies none of the business rules that govern it. Its job is composition and translation, not logic.

The discipline this archetype demands is keeping that boundary firm. Every Edge service should be trivially replaceable — if you rewrote it from scratch, no business rules should be lost, because none should have been there in the first place.

Archetype Four: Data and Read Model Services

Read Model services exist for optimised read access. They do not own source-of-truth data. They consume events from Core Domain services and build optimised views for specific query patterns. Examples include Search, Analytics, and Recommendation engines.

These services emerge from Load and Data forces. Read patterns differ from write patterns — a search service needs complex indexing, an analytics service runs expensive aggregations that should never touch a transactional database. These services subscribe to event streams and update their own internal stores. They can denormalise, pre-join, and index aggressively. Consistency is eventual.

A Product Search service illustrates this well. The Product Core Domain service emits events whenever a product is created or updated. The Search service consumes those events and maintains its own Elasticsearch index, optimised for full-text queries, faceted filtering, and relevance ranking. The transactional product database never receives a search query. Each store is shaped for its purpose.

The critical freedom of this archetype is that you can rebuild the entire service from scratch by replaying the event stream. Drop the index, replay from the beginning, and the service is fully restored.

Archetype Five: Event and Workflow Services

Workflow services coordinate processes that span multiple domains. When a single business transaction must touch three or four Core Domain services, you need something to orchestrate that flow without coupling those services to each other. Examples include order fulfilment orchestrators, saga coordinators, and payment confirmation workflows.

These services emerge from Reliability and Domain forces. The workflow is a distinct business process with its own rules and failure modes. A failure in one step must trigger compensating actions in others — if payment succeeds but inventory reservation fails, the workflow must issue a refund, and that responsibility must live somewhere explicit.

An order fulfilment workflow is the canonical example. The workflow service receives an OrderPlaced event. It calls the Payment service, waits for confirmation, then calls the Inventory service to reserve stock, then notifies the Shipping service. Each step is tracked. If inventory reservation fails after payment has already been captured, the workflow initiates a payment reversal. The individual domain services remain unaware of each other — they only know their own responsibilities.

The service maintains the state of each workflow instance — which steps have completed, which are pending, which have failed. It handles retries, timeouts, and compensating transactions. It must be idempotent: receiving the same event twice cannot corrupt workflow state. Build the compensation logic before the happy path. For every step, define the compensating action first. Only then implement the step itself.

Archetype Six: Infrastructure and Platform Services

Infrastructure services provide shared capabilities that multiple business services depend on — identity, configuration, rate limiting, feature flags, secrets management, translation — but contain no business logic themselves.

These services emerge from Load and Change forces. They are called by nearly every request in the system and must be fast, highly available, and independently scalable. They expose clean interfaces that business services depend on without needing to understand the implementation. Treat them as internal SaaS products.

A translation service is a straightforward example. Every service in the platform may need to display text to a user. The order service needs order confirmation text in the user's language. The product service needs product descriptions. The email service needs notification templates. Instead of each service managing its own translation files and language detection logic, they all call the translation service. Pass in a string identifier and a language code. Get back the translated text. Fast, simple, stateless.

The translation service contains no business rules. It does not decide which language a user should see. It does not know what an order confirmation means. It simply maps an identifier and a language to a string. The business logic lives in the calling services. The translation service just serves the data.

Extract Infrastructure services early. They are safe to extract, they provide immediate leverage across the system, and they pay down the duplication and inconsistency that builds up when every service solves the same operational problems in its own way. Keep them free of business logic — the moment an Infrastructure service starts making business decisions, it has become something else.

Archetype Seven: Anti-Corruption and Adapter Services

Anti-Corruption services protect your internal system from external instability and legacy coupling. Examples include payment gateway abstractions, shipping carrier adapters, legacy system wrappers, and third-party API facades.

These services emerge from Reliability and Domain forces acting at the boundary with external systems. External systems change APIs without notice, use different consistency models, and fail in ways you cannot control. An Anti-Corruption service contains that instability within a single boundary. The external system's model rarely matches your internal domain — a payment gateway thinks about authorisations, captures, and settlements, while your system thinks about orders, payments, and refunds. That translation deserves a dedicated home.

Consider a Payments Adapter wrapping a third-party payment gateway. The rest of your system calls it with your internal domain language: authorisePayment(orderId, amount). The adapter translates that into whatever structure the gateway requires, handles timeouts and retries with exponential backoff, maps the gateway's response codes back to your domain's concepts, and raises a circuit breaker if the gateway becomes unresponsive. When the gateway releases a new API version, one service is updated. Nothing else changes.

The adapter translates and retries. That is all. Business logic — deciding whether to authorise a payment, applying fraud rules, determining which currency to charge — belongs in a Core Domain or Supporting service, not in the adapter.

Archetype Mixtures to Approach Carefully

Archetypes are not purity tests, but some combinations create predictable problems worth knowing in advance.

Edge service carrying business logic. A BFF that accumulates pricing rules, inventory checks, or order validation has become a Core Domain service deployed at the boundary. The solution is to extract that logic into a proper Core Domain service and return the BFF to its role as a thin composition layer.

Workflow calling workflow. When one orchestrator delegates to another, failure boundaries dissolve and debugging requires correlating state across multiple systems simultaneously. Consolidate into a single workflow service or redesign so that each workflow is genuinely independent.

Read model writing back. A Read Model service that writes derived data back to a Core Domain service creates a circular dependency and reintroduces the Data Force the extraction was meant to resolve. Derived state either belongs as a read-time calculation or as a responsibility owned by a dedicated Core Domain service.

Recognising an Archetype: A Quick Diagnostic

Does this service own source-of-truth data that cannot be rebuilt? Core Domain. Treat it with corresponding seriousness.

Could it fail for five minutes without stopping the core business transaction? Supporting. Design for asynchronous communication and graceful degradation.

Does it sit at the system boundary and primarily authenticate, route, or aggregate? Edge. Keep it stateless and free of business logic.

Does it only answer queries and never accept direct writes? Read Model. Extract it safely and rebuild from the event stream when needed.

Does it coordinate multiple steps across domains and manage compensating transactions? Workflow. Build compensation logic before the happy path.

Does it provide a shared capability with no business logic? Infrastructure. Keep it fast, boring, and dependency-free.

Does it wrap an external system and translate between its model and yours? Anti-Corruption. One service per external dependency.

Closing Thought

When teams recognise archetypes emerging from real forces, they build systems that behave correctly even as they evolve. The archetype tells you how the service should communicate, what consistency model it needs, how tolerant it can be of failure, and how often it should change.

Build with the archetype, not against it. The services that last are the ones that fit the pressures that created them.