Building a Modular Monolith gives you clear boundaries between modules, but it also introduces a challenge: how do you query data that lives in different schemas? And how do you maintain data consistency when a business operation spans multiple modules?

In a traditional monolith, you could join tables across the database.

But in a Modular Monolith, each module owns its schema. Direct database access between modules breaks the boundaries you worked hard to establish.

I have been working with Modular Monoliths for years, and I have seen teams struggle with this exact problem. They start with good boundaries, create separate schemas for each module, but then they need to show a report that combines data from three different modules. What do they do?

Some teams give up and start querying across schemas directly. Others try to solve it with complex event chains that are hard to debug. And some just avoid the problem altogether by keeping everything in one module.

But there is a better way.

Today, I want to show you proven approaches for querying data across schemas and strategies for managing transactions in a Modular Monolith.

In this post, we will explore:

• Why You Can't Join Tables Across Multiple Schemas
• Recommended Approaches for Cross-Schema Queries
  • Inter-module API Calls
  • Domain Events with Eventual Consistency
  • Database Views
  • Composite View Pattern (BFF with YARP)
  • Reporting/Analysis Module
• Performing Transactions Across Multiple Schemas
  • Domain Events for Eventual Consistency
  • Transaction across EF Core DbContexts for Strong Consistency
• Choosing Between Eventual and Strong Consistency

Let's dive in!

In a Modular Monolith, each module has its own database schema and DbContext in EF Core. This separation is intentional. It enforces boundaries and makes it possible to extract a module into a microservice later.

But this separation creates two main challenges:

First, you cannot simply join tables across schemas in your queries. If you want to show shipment details along with carrier information and stock levels, you cannot write a single SQL or EF Core query that joins all three schemas.

Second, you cannot use a single database transaction that spans multiple modules. If creating a shipment requires updating stock levels and registering with a carrier, you need a strategy to keep all three operations consistent.

Let me show you a concrete example.

Imagine you need to build a dashboard that shows:

• All shipments created today
• The carrier assigned to each shipment
• Current stock levels for products in those shipments

In a traditional Monolith, you might write something like this:

csharp
1var dashboard = await context.Shipments
2    .Include(s => s.Stocks)
3    .Include(s => s.Carriers)
4    .Where(s => s.CreatedAt.Date == DateTime.UtcNow.Date)
5    .Select(x => new
6    {
7        ShipmentNumber = x.Number,
8        CarrierName = x.Carrier.Name,
9        StockLevel = x.Stocks.First().Quantity
10    })
11    .ToListAsync();

But in a Modular Monolith, this code will not work. The ShipmentsDbContext does not know about Carriers or Stocks entities. They live in different schemas with different DbContexts.

So how do you solve this?

The most straightforward approach is to call other modules through their public APIs. Each module exposes an interface that other modules can use to query data.

This is the approach is the simplest and the cheapest. It respects module boundaries and makes dependencies explicit.

Let's say you need to display shipment details with carrier information. Here is how you would implement it:

First, the Carriers module exposes a public API:

csharp
1public interface ICarrierModuleApi
2{
3    Task<CarrierDetailsResponse?> GetCarrierByNameAsync(
4        string carrierName, 
5        CancellationToken cancellationToken = default);
6}

Now in the Shipments module, you can create a handler that combines data from multiple modules:

csharp
1internal sealed class GetShipmentDetailsHandler(
2    ShipmentsDbContext context,
3    ICarrierModuleApi carrierApi,
4    IStockModuleApi stockApi)
5{
6    public async Task<ErrorOr<ShipmentDetailsResponse>> HandleAsync(
7        string shipmentNumber,
8        CancellationToken cancellationToken)
9    {
10        // 1. Get shipment from the local database
11        var shipment = await context.Shipments
12            .Include(s => s.Items)
13            .FirstOrDefaultAsync(s => s.Number == shipmentNumber, cancellationToken);
14
15        if (shipment is null)
16        {
17            return Error.NotFound("ShipmentNotFound", $"Shipment {shipmentNumber} not found");
18        }
19
20        // 2. Get carrier details from the Carriers module
21        var carrierDetails = await carrierApi.GetCarrierByNameAsync(
22            shipment.Carrier, 
23            cancellationToken);
24
25        // 3. Get stock levels for each product from the Stocks module
26        var stockLevels = new Dictionary<string, int>();
27        foreach (var item in shipment.Items)
28        {
29            var stockResponse = await stockApi.GetStockLevelAsync(item.Product, cancellationToken);
30            if (stockResponse.IsSuccess)
31            {
32                stockLevels[item.Product] = stockResponse.Quantity;
33            }
34        }
35
36        // 4. Combine all data into the response
37        return new ShipmentDetailsResponse
38        {
39            ShipmentNumber = shipment.Number,
40            OrderId = shipment.OrderId,
41            Status = shipment.Status.ToString(),
42            CreatedAt = shipment.CreatedAt,
43            Carrier = carrierDetails,
44            Items = shipment.Items.Select(i => new ShipmentItemDetails
45            {
46                Product = i.Product,
47                Quantity = i.Quantity,
48                CurrentStockLevel = stockLevels.GetValueOrDefault(i.Product, 0)
49            }).ToList()
50        };
51    }
52}

This approach has several advantages:

• Clear boundaries: each module controls what data it exposes
• Type safety: you work with strongly typed interfaces
• Easy to test: you can mock the module APIs in unit tests
• Flexible: each module can change its internal implementation without affecting others

But it also has some drawbacks:

• Multiple database queries: you make separate calls to each module
• N+1 query problem: if you need to enrich a list of shipments with carrier details, you will make one query per shipment

For most scenarios, this approach works well. If you have a few items, the performance overhead is usually acceptable, especially when you add caching or support for bulk operations.

Sometimes you need to query data that does not change frequently. In these cases, you can duplicate the data across modules using integration events.

This approach works well when you need to denormalize data for read performance.

Let's say you want to display the carrier name on the shipment list without having to call the Carriers module each time. You can store the carrier name directly in the Shipments schema.

When a carrier is updated in the Carriers module, it publishes an event:

csharp
1public sealed record CarrierUpdatedEvent(
2    Guid CarrierId,
3    string CarrierName,
4    string ContactEmail,
5    bool IsActive) : IEvent;
6
7internal sealed class UpdateCarrierHandler(
8    CarriersDbContext context,
9    IEventPublisher eventPublisher)
10    : IUpdateCarrierHandler
11{
12    public async Task<ErrorOr<CarrierResponse>> HandleAsync(
13        UpdateCarrierRequest request,
14        CancellationToken cancellationToken)
15    {
16        var carrier = await context.Carriers
17            .FirstOrDefaultAsync(c => c.Id == request.CarrierId, cancellationToken);
18
19        if (carrier is null)
20        {
21            return Error.NotFound("CarrierNotFound", "Carrier not found");
22        }
23
24        carrier.ContactEmail = request.ContactEmail;
25        carrier.PhoneNumber = request.PhoneNumber;
26        carrier.IsActive = request.IsActive;
27
28        // Publish event for other modules
29        var carrierUpdatedEvent = new CarrierUpdatedEvent(
30            carrier.Id,
31            carrier.Name,
32            carrier.ContactEmail,
33            carrier.IsActive);
34
35        await eventPublisher.PublishAsync(carrierUpdatedEvent, cancellationToken);
36        
37        await context.SaveChangesAsync(cancellationToken);
38
39        return carrier.MapToResponse();
40    }
41}

The Shipments module subscribes to this event and updates its local copy:

csharp
1internal sealed class UpdateShipmentCarrierDetailsEventHandler(
2    ShipmentsDbContext context)
3    : IEventHandler<CarrierUpdatedEvent>
4{
5    public async Task HandleAsync(
6        CarrierUpdatedEvent @event,
7        CancellationToken cancellationToken)
8    {
9        var shipments = await context.Shipments
10            .Where(s => s.CarrierName == @event.CarrierName)
11            .ToListAsync(cancellationToken);
12
13        foreach (var shipment in shipments)
14        {
15            shipment.CarrierContactEmail = @event.ContactEmail;
16            shipment.UpdatedAt = DateTime.UtcNow;
17        }
18
19        await context.SaveChangesAsync(cancellationToken);
20    }
21}

Now you can query shipments with carrier details in the Shipments module without having to call the Carriers module.

This approach has the following advantages:

• Fast queries: all data is in one schema, no joins needed
• No runtime dependencies: modules do not need to call each other during queries
• Better performance: single database query instead of multiple calls

But it comes with trade-offs:

• Eventual consistency: data might be temporarily out of sync
• Data duplication: you store the same data in multiple places
• More complex: you need to handle events and keep data synchronized

Use this approach when read performance is critical and you can accept eventual consistency. This approach also allows you to change and scale each module independently.

When using events - I highly recommend using Open Telemetry to monitor your application.

Database views provide a way to query data across multiple schemas at the database level. You create a view that joins tables from different schemas, and then map it to a read-only entity in EF Core.

This approach works well for reporting and analytics scenarios where you need to combine data from multiple modules.

Let's create a view that combines shipments with carrier information:

sql
1CREATE VIEW shipments_report_view AS
2SELECT 
3    s.Id,
4    s.Number,
5    s.OrderId,
6    s.Status,
7    s.CreatedAt,
8    c.Name AS CarrierName,
9    c.ContactEmail AS CarrierContactEmail,
10    c.PhoneNumber AS CarrierPhoneNumber,
11    c.IsActive AS CarrierIsActive
12FROM Shipments.Shipments s
13LEFT JOIN Carriers.Carriers c ON s.Carrier = c.Name
14WHERE c.IsActive = 1;

You can map this view to a read-only entity in EF Core. Create a separate DbContext for read models:

csharp
1public class ShipmentWithCarrier
2{
3    public Guid Id { get; set; }
4    public string Number { get; set; }
5    public string OrderId { get; set; }
6    public string Status { get; set; }
7    public DateTime CreatedAt { get; set; }
8    public string CarrierName { get; set; }
9    public string CarrierContactEmail { get; set; }
10    public string CarrierPhoneNumber { get; set; }
11    public bool CarrierIsActive { get; set; }
12}
13
14public class ReadModelsDbContext(DbContextOptions<ReadModelsDbContext> options)
15    : DbContext(options)
16{
17    public DbSet<ShipmentWithCarrier> ShipmentsWithCarriers { get; set; }
18    
19    protected override void OnModelCreating(ModelBuilder modelBuilder)
20    {
21        base.OnModelCreating(modelBuilder);
22        
23        modelBuilder.Entity<ShipmentWithCarrier>()
24            .HasNoKey()
25            .ToView("shipments_report_view");
26    }
27}

Now you can query the view from your handler:

csharp
1var shipments = await context.ShipmentsWithCarriers
2    .OrderByDescending(s => s.CreatedAt)
3    .Take(request.PageSize)
4    .ToListAsync(cancellationToken);
5
6return shipments.Select(s => new ShipmentWithCarrierResponse
7{
8    ShipmentNumber = s.Number,
9    OrderId = s.OrderId,
10    Status = s.Status,
11    CreatedAt = s.CreatedAt,
12    CarrierName = s.CarrierName,
13    CarrierContactEmail = s.CarrierContactEmail,
14    CarrierPhoneNumber = s.CarrierPhoneNumber
15}).ToList();

This approach has the following advantages:

• Single query: the database handles the join, so you get all data in one query
• Good performance: database views are optimized by the query planner
• Simple code: you query the view like a regular table
• No application-level joins: the database does the heavy lifting

But it has some limitations:

• Breaks module boundaries: the view directly accesses multiple schemas
• Database coupling: modules are coupled at the database level
• Harder to extract to microservices: you need to remove the view first
• Schema changes require view updates: if you change a table structure, you need to update the view

Use database views for reporting and analytics when performance is critical, and you do not plan to extract modules into microservices soon.

I recommend using a separate database user for the database views with restricted permissions.

The Composite View Pattern, also known as Backend for Frontend (BFF), involves creating a separate service that aggregates data from multiple modules. This service sits between your frontend and your Modular Monolith.

This approach is particularly useful when you have complex UI requirements that need data from many modules.

In our case, we can create a BFF service that queries multiple modules and combines the results. To access this BFF service, we use YARP as an API Gateway.

YARP (Yet Another Reverse Proxy) is a reverse proxy toolkit from Microsoft that you can use to route requests to different services. I have written a detailed guide on how to set up YARP as an API Gateway. You can read it here: YARP as API Gateway in .NET.

Here is how the architecture looks:

• Frontend calls YARP Gateway
• YARP routes requests to either the main Modular Monolith or the BFF service
• BFF service queries the Modular Monolith modules and aggregates the data
• BFF returns the combined response to the frontend

Let's create a BFF service that provides a dashboard view:

csharp
1public class ShipmentDashboardService(
2    IHttpClientFactory httpClientFactory)
3{
4    public async Task<ShipmentDashboardResponse> GetDashboardAsync(
5        CancellationToken cancellationToken)
6    {
7        var client = httpClientFactory.CreateClient("ModularMonolith");
8
9        // Query shipments from the Shipments module
10        var shipmentsResponse = await client.GetAsync(
11            "/api/shipments?pageSize=10", 
12            cancellationToken);
13        var shipments = await shipmentsResponse.Content
14            .ReadFromJsonAsync<List<ShipmentResponse>>(cancellationToken);
15
16        // Query carriers from the Carriers module
17        var carriersResponse = await client.GetAsync(
18            "/api/carriers", 
19            cancellationToken);
20        var carriers = await carriersResponse.Content
21            .ReadFromJsonAsync<List<CarrierResponse>>(cancellationToken);
22
23        // Query stock levels from the Stocks module
24        var stocksResponse = await client.GetAsync(
25            "/api/stocks/summary", 
26            cancellationToken);
27        var stockSummary = await stocksResponse.Content
28            .ReadFromJsonAsync<StockSummaryResponse>(cancellationToken);
29
30        // Combine all data into a dashboard view
31        return new ShipmentDashboardResponse
32        {
33            ...
34        };
35    }
36}

The BFF service exposes its own API endpoint:

csharp
1public class DashboardEndpoint : ICarterModule
2{
3    public void AddRoutes(IEndpointRouteBuilder app)
4    {
5        app.MapGet("/api/bff/dashboard", Handle);
6    }
7
8    private static async Task<IResult> Handle(
9        ShipmentDashboardService dashboardService,
10        CancellationToken cancellationToken)
11    {
12        var dashboard = await dashboardService.GetDashboardAsync(cancellationToken);
13        return Results.Ok(dashboard);
14    }
15}

This approach has the following advantages:

• Separation of concerns: the BFF handles UI-specific data aggregation
• Reduced frontend complexity: the frontend makes one call instead of many
• Optimized for UI: you can shape the response exactly as the UI needs it
• Independent scaling: you can scale the BFF separately from the main application
• Better performance for frontend: fewer HTTP calls from the browser

But it has some drawbacks:

• Additional service: you need to deploy and maintain another application
• Network overhead: the BFF makes HTTP calls to the main application
• Duplication: you might duplicate some logic between the BFF and the main application

Use the BFF pattern when you have complex UI requirements that need data from many modules, or when you want to optimize the API for specific frontend needs.

P.S.: For BFF, I can highly recommend using GraphQL. It simplifies a lot of things. If you are interested in GraphQL, you can read my article on HotChocolate GraphQL in .NET.

The final approach is to create a dedicated Reporting or Analysis module that has permission to query multiple schemas. This module is the only one allowed to break the boundary rules.

This approach works well when you need complex reporting or analytics that require data from multiple modules.

The key is to enforce this rule with architecture tests. You can use tools like NetArchTest to ensure that only the Reporting module can access multiple schemas.

I have written a detailed guide on architecture tests. You can read it here: Why Do You Need to Write Architecture Tests in .NET.

With this approach you can create complex reports that join data from multiple modules.

To ensure that only the Reporting module can access multiple schemas, use separate database users for each module. Configure connection strings with specific permissions:

json
1{
2  "ConnectionStrings": {
3    "Shipments": "Server=localhost;Database=ModularMonolith;User Id=shipments_user;Password=***;",
4    "Carriers": "Server=localhost;Database=ModularMonolith;User Id=carriers_user;Password=***;",
5    "Stocks": "Server=localhost;Database=ModularMonolith;User Id=stocks_user;Password=***;",
6    "Reporting": "Server=localhost;Database=ModularMonolith;User Id=reporting_user;Password=***;"
7  }
8}

Grant the reporting user read access to all schemas, while other users only have access to their own schemas.

This approach has the following advantages:

• Powerful queries: you can write complex SQL joins across all schemas
• Good performance: single database query with proper indexes
• Centralized reporting: all reporting logic is in one place

But it has some limitations:

• Breaks module boundaries: the Reporting module knows about other modules' schemas
• Database coupling: modules are coupled at the database level
• Requires discipline: without architecture tests you can break the module boundaries
• Schema changes impact reporting: if you change a table structure, you need to update reports

Use this approach when you need complex reporting and analytics, and you can accept that one module has special privileges.

Querying data across schemas is one challenge, but maintaining data consistency when you modify data in multiple modules is another.

When you create a shipment, you need to update stock levels and register with a carrier. All three operations should succeed or fail together. But each module has its own DbContext and schema.

How do you ensure consistency?

You have two main strategies: eventual consistency with domain events, or strong consistency with a shared transaction.

The first strategy is to use domain events. One module completes its local transaction and publishes an event. Other modules subscribe to this event and perform their own local transactions in response.

This results in eventual consistency. All parts of the system will eventually be consistent, but they might be temporarily out of sync.

Let's see how this works with the CreateShipment use case:

csharp
1internal sealed class CreateShipmentHandler(
2    ShipmentsDbContext context,
3    IStockModuleApi stockApi,
4    IEventPublisher eventPublisher)
5    : ICreateShipmentHandler
6{
7    public async Task<ErrorOr<ShipmentResponse>> HandleAsync(
8        CreateShipmentRequest request,
9        CancellationToken cancellationToken)
10    {
11        // 1. Check if the shipment already exists
12        // 2. Check stock levels (read-only operation)
13        // 3. Save the shipment in the local database
14        
15        var shipment = new Shipment { ... };
16
17        await context.Shipments.AddAsync(shipment, cancellationToken);
18
19        // 4. Publish an event for other modules to react
20        var shipmentCreatedEvent = new ShipmentCreatedEvent(...);
21        await eventPublisher.PublishAsync(shipmentCreatedEvent, cancellationToken);
22        
23        await context.SaveChangesAsync(cancellationToken);
24
25        return shipment.MapToResponse();
26    }
27}

Now the Carriers and Stocks module subscribes to the ShipmentCreatedEvent.

This approach has the following advantages:

• Loose coupling: modules do not depend on each other directly
• Resilience: if one module fails, others can continue
• Scalability: you can process events asynchronously
• Easy to add new handlers: you can add new modules that react to the same event

But it has some challenges:

• Eventual consistency: data might be temporarily out of sync
• Error handling: if an event handler fails, you need a retry mechanism
• Debugging: it is harder to trace the flow of execution
• Complexity: you need to handle partial failures and compensating transactions

For better reliability, you should implement the Outbox pattern. This pattern stores events in the same database transaction as your business data, and then publishes them in a separate process. This ensures that events are never lost.

In a production system, you might use a robust event messaging bus such as RabbitMQ.

The second strategy is to use a shared transaction across multiple DbContexts. This gives you strong consistency: either all operations succeed, or all fail together.

To implement this, you need a TransactionManager that coordinates the transaction across multiple modules.

Here is the TransactionManager implementation:

csharp
1public interface ITransactionManager
2{
3    IDbContextTransaction? CurrentTransaction { get; }
4    
5    SetTransaction(IDbContextTransaction transaction);
6    
7    Task CommitTransactionAsync(CancellationToken cancellationToken = default);
8    Task RollbackTransactionAsync(CancellationToken cancellationToken = default);
9}
10
11public class TransactionManager : ITransactionManager
12{
13    private IDbContextTransaction? _currentTransaction;
14
15    public IDbContextTransaction? CurrentTransaction => _currentTransaction;
16    
17    public void SetTransaction(IDbContextTransaction transaction)
18    {
19        _currentTransaction = transaction;
20    }
21
22    public async Task CommitTransactionAsync(CancellationToken cancellationToken = default)
23    {
24        if (_currentTransaction == null)
25        {
26            throw new InvalidOperationException("No transaction in progress");
27        }
28
29        try
30        {
31            await _currentTransaction.CommitAsync(cancellationToken);
32        }
33        finally
34        {
35            _currentTransaction.Dispose();
36            _currentTransaction = null;
37        }
38    }
39
40    public async Task RollbackTransactionAsync(CancellationToken cancellationToken = default)
41    {
42        if (_currentTransaction == null)
43        {
44            return;
45        }
46
47        try
48        {
49            await _currentTransaction.RollbackAsync(cancellationToken);
50        }
51        finally
52        {
53            _currentTransaction.Dispose();
54            _currentTransaction = null;
55        }
56    }
57}

Register the TransactionManager as a scoped service:

csharp
1builder.Services.AddScoped<ITransactionManager, TransactionManager>();

Now update your DbContexts to use the shared transaction:

csharp
1public class ShipmentsDbContext : DbContext
2{
3    private readonly ITransactionManager _transactionManager;
4
5    public ShipmentsDbContext(
6        DbContextOptions<ShipmentsDbContext> options,
7        ITransactionManager transactionManager) : base(options)
8    {
9        _transactionManager = transactionManager;
10    }
11
12    public DbSet<Shipment> Shipments { get; set; }
13    public DbSet<ShipmentItem> ShipmentItems { get; set; }
14
15    public override async Task<int> SaveChangesAsync(CancellationToken cancellationToken = default)
16    {
17        // If there is a shared transaction, use it
18        if (_transactionManager.CurrentTransaction != null && Database.CurrentTransaction == null)
19        {
20            await Database.UseTransactionAsync(
21                _transactionManager.CurrentTransaction.GetDbTransaction(), cancellationToken);
22        }
23
24        return await base.SaveChangesAsync(cancellationToken);
25    }
26
27    protected override void OnModelCreating(ModelBuilder modelBuilder)
28    {
29        base.OnModelCreating(modelBuilder);
30        modelBuilder.HasDefaultSchema(DbConsts.ShipmentsSchemaName);
31    }
32}

Do the same for CarriersDbContext and StocksDbContext.

Now you can use the TransactionManager in your handler:

csharp
1public async Task<ErrorOr<ShipmentResponse>> HandleAsync(
2    CreateShipmentRequest request,
3    CancellationToken cancellationToken)
4{
5    // Start a shared transaction
6    var transaction = await shipmentsContext.Database.BeginTransactionAsync(cancellationToken);
7    transactionManager.SetTransaction(transaction);
8
9    // ...
10        
11    await stocksContext.SaveChangesAsync(cancellationToken);
12    await shipmentsContext.SaveChangesAsync(cancellationToken);
13    await carriersContext.SaveChangesAsync(cancellationToken);
14
15    await transactionManager.CommitTransactionAsync(cancellationToken);
16
17    return shipment.MapToResponse();
18}

This approach has the following advantages:

• Strong consistency: all operations succeed or fail together
• ACID guarantees: you get the full benefits of database transactions
• Simpler error handling: if anything fails, everything rolls back
• Easier to reason about: the flow is linear and predictable

But it has some drawbacks:

• Tight coupling: the handler needs to know about all DbContexts
• Breaks module boundaries: you are directly accessing other modules' DbContexts
• Harder to extract to microservices: you need to remove the coupled transaction

Use this approach when you absolutely need strong consistency and cannot accept any temporary inconsistency.

I recommend using a separate database user for this kind of TransactionManager that is not available to other modules.

Now that you have seen both approaches, how do you decide which one to use?

The answer depends on your business requirements. Let me walk you through some practical scenarios.

Eventual consistency with domain events is the better choice in most scenarios. Here is when you should use it:

Scenario 1: Order Processing

When a customer places an order, you create a shipment, update stock levels, and notify the carrier. If the carrier notification fails, it does not affect the customer's order. You can retry the notification later.

In this case, eventual consistency is acceptable. The shipment is created, stock is updated, and the carrier will be notified eventually.

Scenario 2: Analytics and Reporting

When you update a shipment status, you might want to update analytics data in a separate module. The analytics data does not need to be updated immediately. It can be updated within a few seconds or within a few minutes.

Eventual consistency is perfect for this scenario.

Scenario 3: Sending Notifications

When a shipment is created, you want to send an email to the customer. If the email service is temporarily down, you do not want to fail the entire shipment creation. You can retry sending the email later.

Again, eventual consistency is the right choice.

Scenario 4: Cross-Module Data Synchronization

When carrier information changes, you want to update the denormalized carrier data in the Shipments module. This update does not need to happen immediately. It can happen a few seconds later.

Eventual consistency works well here.

The key insight is this: if a failure in one module should not prevent the main operation from succeeding, use eventual consistency.

Eventual consistency gives you better resilience, scalability, and loose coupling. Your system can continue to function even if some parts are temporarily unavailable.

Strong consistency with a shared transaction is necessary when you absolutely cannot accept any temporary inconsistency.

Here is when you should use it:

Scenario 1: Financial Transactions

When you process a payment, you need to deduct money from one account and add it to another. Both operations must succeed or fail together. You cannot have a situation where money is deducted but not added.

In this case, you need strong consistency with a database transaction.

Scenario 2: Inventory Reservation

When a customer adds a product to their cart and proceeds to checkout, you need to reserve the inventory. If the reservation fails, the checkout should fail as well. You cannot sell more products than you have in stock.

Strong consistency is required here.

Scenario 3: Booking Systems

When a customer books a hotel room or a flight seat, you need to mark it as unavailable immediately. You cannot have two customers booking the same room or seat.

You need strong consistency to prevent double booking.

In practice, you will often use a hybrid approach. Use strong consistency for critical operations like inventory updates and financial transactions. Use eventual consistency for non-critical operations, such as notifications and analytics.

The key is to understand your business requirements and choose the right approach for each scenario. Do not default to strong consistency everywhere.

Eventual consistency is often good enough and gives you better resilience and scalability.

Remember that a Modular Monolith is about maintaining clear boundaries while keeping everything in a single deployable unit. These patterns help you maintain those boundaries while still allowing modules to work together effectively.

Hope you find this newsletter useful. See you next time.