When to Extract a Module Into a Microservice

Extract a module into a microservice only when you have a concrete driver: independent scaling, a separate deployment cadence, a different technology stack, or hard fault isolation. Without one of those, extraction adds operational cost for no benefit. The module also has to be ready: a clean public API, isolated data, and event-based communication. Here are the signals, the readiness checklist, and an extraction process that keeps a rollback path open.

The Extraction Promise

"We can always extract it into a microservice later" is the promise that sells the modular monolith. It's a real promise, but it depends on knowing when "later" has arrived, and how to extract without breaking what already works. Extracting a module means taking code that runs in-process inside the monolith and deploying it as a separate service that communicates over the network.

Extract too early, before the module boundaries are stable, and you end up with a distributed monolith. Wait too long, and extraction becomes a multi-month rewrite.

The key is understanding the signals that tell you extraction is the right move.

When Should You Extract a Module?

Independent Scaling Requirements

If one module needs 10x the compute resources of the rest, deploying everything together wastes resources. A notification module sending millions of emails shouldn't force you to scale the entire application.

Before reaching for extraction, check whether scaling the whole monolith horizontally is cheaper. It often is, until the load asymmetry gets extreme.

Module                   | Avg Load      | Peak Load
-------------------------|---------------|----------
Catalog                  | Low           | Low
Ordering                 | Medium        | Medium
NotificationProcessing   | Low           | Very High  ← extraction candidate
UserManagement           | Low           | Low

Different Deployment Cadences

If one team needs to deploy their module five times a day while the rest deploys weekly, they're blocked by the monolith's deployment cycle. Independent deployment is a microservice benefit that matters here.

Technology Requirements

A module might benefit from a different technology stack. Maybe the search module needs Elasticsearch-native code, or the ML pipeline needs Python. In a monolith, you're locked to .NET for everything.

Fault Isolation

If a bug in one module crashes the entire application, extraction provides fault isolation. The notification module throwing an out-of-memory exception shouldn't take down the ordering module.

Signs You Should NOT Extract

The Boundaries Are Still Shifting

If module boundaries are still changing - endpoints move between modules, shared types keep growing - extraction will lock in the wrong boundaries as network contracts.

Strong Data Coupling

If two modules frequently join each other's data, separating them means replacing SQL joins with API calls. That's a performance and reliability hit. Fix the data isolation first.

You Want to "Try Microservices"

Extracting a module to learn microservices is expensive learning. The modular monolith gives you most of the modularity benefits without the operational complexity.

Small Team

A modular monolith suits teams of roughly 2-15 developers. If your engineering team is still inside that range, the coordination overhead of microservices usually outweighs the benefits. A modular monolith with clear module communication is simpler to operate.

Readiness Checklist

Before extracting, verify these preconditions:

// Your module should already have:

// 1. Clean public API (no direct database access from other modules)
public interface ICatalogModule
{
    Task<ProductResponse> GetProductAsync(Guid productId);
    Task<bool> CheckAvailabilityAsync(Guid productId, int quantity);
    Task ReserveStockAsync(Guid orderId, List<OrderItem> items);
}

// 2. Own database/schema (data isolation enforced)
public class CatalogDbContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("catalog");
    }
}

// 3. Event-based communication (not synchronous method calls)
public class OrderPlacedEventHandler
    : IIntegrationEventHandler<OrderPlacedIntegrationEvent>
{
    public async Task HandleAsync(
        OrderPlacedIntegrationEvent @event,
        CancellationToken cancellationToken = default) { /* ... */ }
}

The IIntegrationEvent contracts and handler abstractions come from the shared kernel.

If any of these are missing, fix them first. Extraction without these foundations creates a distributed monolith.

The Extraction Process

Step 1: Verify Data Isolation

Ensure the module uses its own database or schema. Query the database to find any cross-module references:

-- Find foreign keys crossing module boundaries (PostgreSQL)
SELECT
    con.conname AS constraint_name,
    child_ns.nspname AS child_schema,
    child.relname AS child_table,
    parent_ns.nspname AS referenced_schema,
    parent.relname AS referenced_table
FROM pg_constraint con
JOIN pg_class child ON con.conrelid = child.oid
JOIN pg_namespace child_ns ON child.relnamespace = child_ns.oid
JOIN pg_class parent ON con.confrelid = parent.oid
JOIN pg_namespace parent_ns ON parent.relnamespace = parent_ns.oid
WHERE con.contype = 'f'
  AND child_ns.nspname <> parent_ns.nspname;

If you find cross-module foreign keys, remove them and replace them with eventual consistency through integration events.

Step 2: Replace In-Process Communication With HTTP/Messaging

Module interfaces that were resolved via dependency injection now need to go over the network.

// Before: In-process call
public class OrderService
{
    private readonly ICatalogModule _catalog;

    public async Task PlaceOrder(PlaceOrderCommand command)
    {
        var available = await _catalog.CheckAvailabilityAsync(
            command.ProductId, command.Quantity);
    }
}

// After: HTTP client call
public class CatalogApiClient : ICatalogModule
{
    private readonly HttpClient _httpClient;

    public CatalogApiClient(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<bool> CheckAvailabilityAsync(
        Guid productId, int quantity)
    {
        var response = await _httpClient.GetAsync(
            $"/api/catalog/products/{productId}/availability?quantity={quantity}");

        response.EnsureSuccessStatusCode();

        return await response.Content.ReadFromJsonAsync<bool>();
    }

    // GetProductAsync and ReserveStockAsync follow the same pattern
}

The key insight: the ICatalogModule interface doesn't change. Only the implementation switches from in-process to HTTP. This is why clean module APIs matter.

The new network hop also brings network failure modes. Wrap the HTTP client with retries and a circuit breaker, and set explicit timeouts. An in-process call could never time out; this one can.

Step 3: Replace In-Memory Events With a Message Broker

If you were using an in-memory event bus, switch to a real broker (RabbitMQ, Azure Service Bus) through a library like MassTransit. The publishing call barely changes (_publishEndpoint is MassTransit's IPublishEndpoint):

// Before: in-process event bus
await _eventBus.PublishAsync(integrationEvent, ct);

// After: message broker publish with MassTransit
await _publishEndpoint.Publish(integrationEvent, ct);

The outbox pattern becomes critical here since network calls to the broker can fail.

Step 4: Deploy Independently

Create a separate deployment pipeline for the extracted module. It gets its own:

• Repository (or folder in a monorepo)
• CI/CD pipeline
• Container/hosting environment
• Database instance

Strangler Fig Approach

Don't extract everything at once. Use the strangler fig pattern:

1. Deploy the new microservice alongside the monolith
2. Route traffic for the extracted module to the new service
3. Keep both running until the new service is proven stable
4. Remove the module from the monolith

This gives you a rollback path if the extraction causes issues.

I walk through this migration in detail in Breaking It Down: How to Migrate Your Modular Monolith to Microservices.

Key Takeaways

1. Extract when you have concrete scaling, deployment, or fault-isolation needs - not because microservices are trendy.
2. Verify your module has clean APIs, isolated data, and event-based communication before extracting.
3. The module interface stays the same; only the implementation changes from in-process to network calls.
4. Replace in-memory events with a message broker and use the outbox pattern for reliability.
5. Use the strangler fig approach for safe, incremental extraction.
6. If boundaries are unstable or data is tightly coupled, fix the monolith first.

Thanks for reading, and stay awesome!