Every multi-step use case needs a business coordination strategy: a design for how its steps proceed, fail, and recover across the participants involved. But before you can choose a strategy, you need to know what kind of use case you’re looking at.
Most teams skip this step. They jump straight to picking a mechanism (Saga, outbox, a workflow engine) without first asking a more basic question: who owns the coordination? That single question, answered honestly, splits use cases into four types. Each type has a different correctness contract, a different failure surface, and a recognizable signature in the ERD.
Why “who coordinates” is the right axis
A use case is defined by intent, outcome, and failure/recovery semantics at the user-goal level. It is triggered by an entry point (an HTTP request, a cron job, a queue consumer, an admin command), but the trigger is not the use case. What actually distinguishes one use case from another, structurally, is where the responsibility for sequencing and recovery lives.
Coordination ownership can sit in one of four places. That gives us the taxonomy.
1. Self-coordinated
The use case completes within a single context, against a single transactional boundary. There is no cross-participant sequencing to manage because everything that must change, changes together under one ACID transaction.
Contract: atomicity is sufficient. If the transaction commits, the use case succeeded; if it rolls back, nothing happened.
ERD signature: the affected entities sit inside one cluster, connected by mandatory relationships and composition. No foreign keys cross a context line.
Example: updating a user’s display name. One row, one boundary, done.
This is the only type where the database transaction genuinely is the coordination strategy. For everything below, ACID covers one node of a graph that already spans more.
2. Server-coordinated
The use case spans multiple contexts, but a single server-side actor owns the sequencing. It calls each step, observes the results, and decides how to proceed or compensate when a step fails. The user issues one intent and waits for one outcome.
Contract: correctness includes the recovery path. A failed payment after a reserved inventory slot is not a rollback; it’s a compensating action (release the reservation) that the coordinator is responsible for invoking.
ERD signature: thin, reference-only links between clusters, with the coordinator’s context holding the status fields that track progress through the steps. Lifecycle state lives here.
Example: checkout. Reserve stock, charge the card, create the order, send confirmation. One coordinator drives the whole sequence.
This is where orchestrated workflows, TCC, and orchestration-style Sagas typically land.
3. Client-coordinated
The client (a browser, mobile app, or calling service) owns the sequencing. It issues several independent calls and is responsible for what happens between them. The server exposes the steps; it does not stitch them together.
Contract: each server-side step is independently correct and idempotent, because the coordinator is outside your trust boundary and may retry, abandon, or interleave calls in ways you don’t control.
ERD signature: independent clusters with no server-side status field linking the steps. The “in between” state exists only on the client.
Example: a wizard-style flow where the front end saves a draft, uploads attachments, then submits, each as a separate call. If the user closes the tab between steps, the server has no obligation to finish.
The risk here is implicit coordination: a sequence the client depends on but no one designed for failure. If losing the client mid-flow corrupts a business invariant, the coordination shouldn’t have lived on the client.
4. External-coordinated
The sequence is driven by a participant you don’t own and can’t command: a payment provider’s webhook, a partner’s batch file, a regulatory clearing process. You react to events on someone else’s schedule.
Contract: correctness is about reconciliation, not control. You can’t roll back the external party, so you converge: idempotent event handling, outbox-and-reconcile, and explicit handling of out-of-order or duplicate signals.
ERD signature: entities carrying external reference IDs and status fields that mirror an external lifecycle, often with reconciliation timestamps. The status transitions are dictated from outside.
Example: settling a payment via provider webhooks. The provider tells you when funds clear; your job is to record it correctly no matter how many times or in what order the notifications arrive.
Why the taxonomy earns its keep
The four types map cleanly onto the strategy-first principle: the type tells you what the use case requires before you argue about how to implement it.
- Self-coordinated needs nothing beyond a transaction.
- Server-coordinated needs a coordinator and explicit compensation.
- Client-coordinated needs idempotent, independently-valid steps.
- External-coordinated needs reconciliation against a lifecycle you don’t own.
Mislabel the type and you’ll reach for the wrong mechanism. Try to make a client-coordinated flow behave like a server-coordinated one and you’ll bolt fragile sequencing logic onto a client you can’t trust. Try to ACID your way through an external-coordinated settlement and you’ll discover the external party never agreed to your transaction boundary.
And there’s a sharper diagnostic hiding here. If your coordination strategy is working to hold together an invariant that should have stayed inside one transaction, the boundary is wrong, not the strategy. The four types help you see that: a use case that keeps wanting to be self-coordinated but has been split into server-coordinated steps is telling you the split was drawn through the middle of an aggregate.
This is what the ERD makes visible. Coordination ownership isn’t an abstract design choice; it leaves structural fingerprints in relationships, status fields, and reference IDs. Read those fingerprints, and the type of use case (and the strategy it demands) stops being a guess.