Transaktioner & concurrency — när två skribenter krockar

Optimistic concurrency — den enkla idén

Vid läsning noterar du vilken version aggregatet hade. Vid skrivning säger du "jag förväntar mig att versionen fortfarande är 7". Om någon annan hann skriva däremellan så kastar databasen ett fel.

Hantera konflikten — retry med Polly

I många fall är en konflikt bara olycklig timing — om vi laddar om aggregatet, applicerar commandot igen och försöker spara så kommer det att lyckas. Det här är ett perfekt jobb för Polly.

var retry = Policy
    .Handle<ConcurrencyConflictException>()
    .WaitAndRetryAsync(
        retryCount: 3,
        sleepDurationProvider: attempt => TimeSpan.FromMilliseconds(50 * Math.Pow(2, attempt)));

public async Task<DepositMoneyResult> Handle(DepositMoneyCommand cmd, CancellationToken ct)
{
    return await retry.ExecuteAsync(async () =>
    {
        var account = await _repo.LoadAsync(cmd.Account, ct)
            ?? throw new NotFoundException(cmd.Account);

        account.Deposit(new Money(cmd.Amount, cmd.Currency), cmd.Reference);
        await _repo.SaveAsync(account, ct);

        return new DepositMoneyResult(account.Version, account.Balance.Amount);
    });
}

Stor fördel med single-database-setup

Eftersom event store (dbo.Messages) och alla read model-tabeller ligger i samma MSSQL kan vi använda en transaktion när vi uppdaterar read modellen från projektionen. Då försvinner hela dual-write-problemet.

using var scope = new TransactionScope(
    TransactionScopeOption.Required,
    new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted },
    TransactionScopeAsyncFlowOption.Enabled);

await using var conn = new SqlConnection(_cs);
await conn.OpenAsync(ct);

await UpdateReadModelAsync(conn, evt, ct);          // INSERT/UPDATE dbo.AccountSummary
await WriteCheckpointAsync(conn, evt.Position, ct); // MERGE dbo.ProjectionCheckpoints

scope.Complete();

Utan transaktion: read model uppdateras, processen kraschar, checkpoint skrivs aldrig → samma event processas igen → dubblerad data. Med transaktion: båda eller ingen → exactly-once.

När behöver vi outbox då?

Outbox-mönstret behövs när du måste skriva till två olika systems i samma transaktion — typexempel: spara event i databasen och publicera till en message bus (RabbitMQ, Kafka, Azure Service Bus). Det går inte att göra atomärt över olika resurser, så vi använder en mellantabell.

CREATE TABLE dbo.Outbox (
    Id           BIGINT IDENTITY PRIMARY KEY,
    EventType    NVARCHAR(400) NOT NULL,
    PayloadJson  NVARCHAR(MAX) NOT NULL,
    OccurredAt   DATETIMEOFFSET NOT NULL,
    PublishedAt  DATETIMEOFFSET NULL
);

Skrivning sker i samma transaktion som event-append. En separat OutboxRelay : BackgroundService pollar tabellen efter rader där PublishedAt IS NULL, publicerar till bussen och uppdaterar PublishedAt.

Idempotens på handler-nivå — repris

Från lektion 4: klienten skickar en MessageId. IdempotencyBehavior kollar tabellen dbo.IdempotencyKeys:

CREATE TABLE dbo.IdempotencyKeys (
    MessageId  UNIQUEIDENTIFIER PRIMARY KEY,
    Result     NVARCHAR(MAX) NOT NULL,
    CreatedAt  DATETIMEOFFSET NOT NULL
);

CREATE INDEX IX_IdempotencyKeys_CreatedAt ON dbo.IdempotencyKeys(CreatedAt);
-- Periodisk städning av rader äldre än t.ex. 30 dagar

Detta skyddar mot: klienten retryar pga timeout, nätverket blinkar mellan API och DB, dubbelklick i UI:t. Tillsammans med retry-policyn på handlern blir hela kedjan robust.

Concurrency-flöde — exempel

// Två användare gör DepositMoney på samma konto samtidigt.
//
// T1: Load(account) → Version = 7
// T2: Load(account) → Version = 7
// T1: account.Deposit(100) → ny event, Version blir 8
// T1: Save() → AppendToStream(streamId, expectedVersion: 7, [event]) → OK
//
// T2: account.Deposit(50) → ny event, Version blir 8
// T2: Save() → AppendToStream(streamId, expectedVersion: 7, [event])
//      → ConcurrencyConflictException
//
// Polly:
//   T2 (försök 2): Load(account) → Version = 8 (T1:s ändring syns)
//                  account.Deposit(50) → ny event, Version blir 9
//                  Save() → AppendToStream(streamId, expectedVersion: 8, ...) → OK

Isolationsnivåer

Single-writer per aggregat

Even with optimistic concurrency så får du bättre prestanda om du aldrig har två trådar som skriver till samma aggregat samtidigt. Detta uppnås med en in-memory kö per StreamId — vilket är exakt vad vi bygger i nästa lektion (08 · Command-kö & Undo).

Sammanfattning

• Optimistic concurrency = unique constraint på (StreamId, Version) + expectedVersion vid append.
• Konflikter hanteras med Polly-retry (3 försök, exponentiell backoff) ovanpå ladda-om-applicera-spara.
• Allt i samma MSSQL → TransactionScope ger exactly-once-projektion utan outbox.
• Outbox-mönstret behövs först när vi publicerar utåt (message bus).
• Idempotency-key + retry-policy + single-writer-per-aggregat = robust skrivkedja.

← Föregående: SqlStreamStore & projektioner Nästa: Command-kö & Undo →