Persistence & Coordination Patterns

Architectural Patterns are Bundles of Guarantees

A useful backend architecture does not start by choosing one pattern for the whole system. It starts by identifying what must remain true when work crosses boundaries.

Cohesive separates that question into operational dimensions:

• Persistence: what is made durable and authoritative?
• Reconstitution: how is usable state recovered from durable material?
• Interaction and delivery: how do observers exchange work, and what are the delivery guarantees?
• Commit and coordination: which effects must commit together, and how is multi-participant work made consistent?
• Recovery and idempotency: what happens after crash, retry, redelivery, replay, or partial progress?

These dimensions are independent. A broker can accept a message without making a domain transition correct. A workflow engine can retry an activity without defining entity invariants. An actor runtime can serialize work for one identity without making that state durable. A database can commit a row without telling downstream observers what changed.

The Boundary Ladder

Engineers often use one word, "success" or "completion" for several different boundaries, but those boundaries are not equivalent:

• transport accepted bytes
• broker accepted message
• consumer received input
• consumer acknowledged or committed offset
• domain transition committed
• outbox publication responsibility committed
• downstream observer processed input
• downstream entity transition committed
• read model caught up
• business transaction completed

A success at one boundary does not imply success at the others.

An HTTP 200 can mean the transport finished, not that a downstream business process completed. A broker acknowledgment can mean the broker retained a message, not that the consumer updated its local state. A committed offset can mean the consumer promised not to read the input again, not that the domain transition committed safely. A read model can lag even when the write side is correct.

Architecture must be explicit about which boundary each guarantee applies to. Cohesive makes those boundaries part of the system model instead of leaving them implicit in infrastructure behavior.

Persistence and Reconstitution

Persistence asks what becomes durable and authoritative. A system might persist current rows, documents, aggregate snapshots, appended events, outbox records, inbox records, retained messages, offsets, workflow history, projection rows, or search documents.

Reconstitution asks how state is recovered from durable storage. A service can load the latest row. An aggregate can hydrate from a repository. An event-sourced entity can replay a stream, possibly from a snapshot. A projector can rebuild a read model. A workflow can replay history or resume from a checkpoint. A consumer can resume from offsets or redeliver retained inputs.

The choice of persistence mechanism determines which reconstitution paths are available, and therefore which guarantees the system can make about state recovery after failure.

Commit Boundaries and The Dual-Write Problem

Many reliability bugs are commit-boundary bugs. The simplest form is the dual-write problem:

If those effects do not share a commit boundary or a recovery protocol, two bad outcomes appear:

• The database commit succeeds, but message publication fails. Authoritative state changed, but downstream observers are never told.
• Message publication succeeds, but the database commit fails. Downstream observers react to a fact that did not commit.

This is not only a database-plus-broker issue. The same failure mode appears in many pairs:

• entity transition plus search index update
• broker offset commit plus local database update
• workflow checkpoint plus external API call
• event append plus unrelated broker write
• local state change plus notification

This is not a timing issue. It is a commit-boundary issue. "Do this, then that" is not a correctness proof when the process can crash between the two effects.

Outbox, Event Sourcing, and Atomic Coordination

Outbox and event sourcing are both ways to address the dual-write problem by atomically combining persistence with coordination material.

Outbox does this by committing the local state change and the responsibility to publish in the same atomic boundary:

Event sourcing does this by committing the event history as the durable source for both state reconstitution and downstream coordination. The event append is both the local commit and the coordination trigger. Entity state is reconstituted from the committed history, and projections, process managers, subscribers, and publishers can derive their work from that same history.

Atomic coordination does not mean exactly-once messaging, immediate consistency, downstream completion, or read-model freshness. Publication and downstream processing remain asynchronous, so ordering, retry, redelivery, deduplication, and consumer correctness still need design.

Neither pattern eliminates commit-boundary problems on its own. The correctness claim depends on the coordination material being committed in the same atomic boundary as the authoritative change, or being derived reliably from material that was. If a system persists state and separately emits coordination material with no atomic commit or recovery derivation, it reintroduces the dual-write problem.

Inbox, Idempotency, and Recovery

Outbox solves the producer-side handoff. It does not solve consumer-side duplication.

The consumer-side complement is a transactional inbox or another idempotent receiver strategy:

The consumer must decide when it is safe to acknowledge the delivery. If it acknowledges before the local transition commits, a crash can lose work. If it commits locally but crashes before acknowledgment, the broker may redeliver the input.

Effectively-once processing is therefore achieved through cross-participant constraints, not a single broker feature. It usually depends on:

• local atomic commits
• stable input identifiers
• deduplication or inbox records
• expected-version checks
• idempotent interpretation
• explicit acknowledgment timing
• retry and recovery

Recovery mechanisms must account for these moving parts to maintain correctness after crashes, retries, redelivery, replay, or partial progress.

How Patterns Compose

Patterns give compact names for recurring operational concerns and the solutions that address them.

A real system usually composes several of these at once.

The architecture is not the name of any one component. It is the composed set of guarantees across the boundaries where facts, triggers, deliveries, receipts, and follow-up transitions move.

Infrastructure as Realization Substrate

Infrastructure components are realization substrates, not architectures. They must be configured and composed so the system actually satisfies the required operational semantics.

Choosing infrastructure is therefore the second step. The first step is naming the semantics the substrate must preserve.

For the Cohesive-specific realization model, see Cohesive.Infra, which binds compute, runtimes, services, capabilities, and projection targets to the semantics they must preserve.

A Cohesive View

Cohesive captures semantic structure independently of any one realization. Persistence, execution, indexing, messaging, API, and infrastructure can all be bound to the model while the semantics themselves remain stable.

• Cohesive.Entities captures entity transitions, invariants, and effects that can be bound to storage, runtimes, indexes, messaging, and API surfaces.
• Cohesive.Api models APIs independently of a transport realization such as ASP.NET, OpenAPI, AsyncAPI, gRPC, or GraphQL, while still binding API operations to entity and process models.
• Cohesive.Processes captures multi-step coordination so it can be bound to workflow runtimes or durable execution engines.
• Cohesive.Relations captures relationships for queries, hydration, DTOs, and indexing without requiring the underlying database to be relational.
• Cohesive.Infra models infrastructure semantics and binds those blocks to realization substrates.

The same semantic structure can be viewed through several authoring surfaces:

public sealed class Tender : Entity<Tender>
{
    public sealed record AcceptTenderInput(string PartnerId, DateTimeOffset AcceptedAt);
    public sealed record Emit990Accept(string TenderId, string PartnerId) : IEffectRequest<Nothing>;
 
    public Tender()
    {
        Status = Field(nameof(Status), TenderStatus.Pending);
        Expiration = Field<DateTimeOffset>(nameof(Expiration));
        PartnerId = Field<string?>(nameof(PartnerId), initialValue: null);
        AcceptedAt = Field<DateTimeOffset?>(nameof(AcceptedAt), initialValue: null);
 
        AcceptTender = Transition<AcceptTenderInput>(
            nameof(AcceptTender),
            t => t
                .Requires("CanAccept", (tender, input) =>
                    tender.Status == TenderStatus.Pending &&
                    tender.Expiration > input.AcceptedAt
                )
                .Set(tender => tender.Status, (_, _) => TenderStatus.Accepted)
                .Set(tender => tender.PartnerId, (_, input) => input.PartnerId)
                .Set(tender => tender.AcceptedAt, (_, input) => input.AcceptedAt)
                .EmitSnapshot("TenderAccepted", (snapshot, input) => new
                {
                    tenderId = snapshot.EntityId.Value,
                    partnerId = input.PartnerId
                })
                .RequestSnapshot<Emit990Accept, Nothing>((snapshot, input) =>
                    new(snapshot.EntityId.Value, input.PartnerId)));
    }
 
    public Field<TenderStatus> Status { get; }
    public Field<DateTimeOffset> Expiration { get; }
    public Field<string?> PartnerId { get; }
    public Field<DateTimeOffset?> AcceptedAt { get; }
    public Transition<Tender, AcceptTenderInput> AcceptTender { get; }
}
 
// Runtime evaluation: the transition is applied to an observed entity state.
var tender = new Tender();
var state = tender.CreateState("tender-123", new
{
    Status = TenderStatus.Pending,
    Expiration = DateTimeOffset.UtcNow.AddHours(4)
});
 
var result = tender.AcceptTender.Apply(
    state,
    new Tender.AcceptTenderInput("partner-42", DateTimeOffset.UtcNow)
);
 
// result.State contains the accepted tender.
// result.Effects contains TenderAccepted and Emit990Accept coordination material.

The result is not a pattern taxonomy. It is an explicit path from semantic intent to the operational choices that preserve that intent across persistence, delivery, commit, coordination, and recovery boundaries.