Why should you care?

ShopNest order placement (write) needs transactions; dashboard analytics (read) needs heavy joins — splitting avoids compromising both.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

// Command side
public async Task<int> Handle(PlaceOrderCommand cmd, CancellationToken ct)
{
    var order = new Order { CustomerId = cmd.CustomerId };
    _writeDb.Orders.Add(order);
    await _writeDb.SaveChangesAsync(ct);
    return order.Id;
}

// Query side
public async Task<OrderSummaryDto?> Handle(GetOrderSummaryQuery q, CancellationToken ct) =>
    await _readDb.Orders.AsNoTracking()
        .Where(o => o.Id == q.OrderId)
        .Select(o => new OrderSummaryDto(o.Id, o.OrderDate, o.Items.Sum(i => i.Quantity * i.UnitPrice)))
        .FirstOrDefaultAsync(ct);

What happened?

• Write DbContext tracks Order insert.
• Read DbContext projects DTO without tracking — can point to read replica connection string.

Practice next

1. Identify commands vs queries in ShopNest features.
2. Use MediatR or separate service classes per side.
3. Share schema; optionally separate read connection.
4. Register WriteDbContext and ReadDbContext with different connection strings.
5. Denormalize OrderSummary table updated by domain events for extreme read scale.

Remember

Commands write; queries read optimized. EF patterns differ per side. Read replica optional for query DbContext.

ShopNest order write/read split

Place order uses write context; order tracking page uses read context with projection.

Outcome: Analytics queries no longer lock checkout OLTP tables.