Orchestration and choreography.
Two ways to coordinate services, and when each one suits a signing process.
When a process involves many services, something has to coordinate them. In software architecture there are two main ways of doing this, known by names borrowed from music and dance: orchestration and choreography. The difference looks technical, but it changes where the process logic lives, how it recovers from errors, and how what happened is proven.
Two models
| Orchestration | Choreography | |
|---|---|---|
| Idea | A conductor knows the score and tells each service what to do and when. | Each service knows its part and reacts to the events of the others. |
| Where the process lives | In a single place. | Spread across the participants. |
| Strength | The whole process is visible, the order is controlled, and every step is recorded. | Loose coupling: participants can be added without touching the others. |
| Risk | The conductor becomes a bottleneck if it concentrates everything. | No one sees the whole process, and errors are hard to trace. |
Why signing calls for orchestration at the core
A signing process has requirements that favor a conductor: the order of signers matters, every step must be recorded in a single body of evidence, and when something fails, you need to know exactly what state the document was left in. Spreading that logic across services that react to events would make it very hard to tell the complete story years later.
And choreography at the edges
What happens before and after the signature, on the other hand, benefits from choreography. When a document is signed, the platform publishes an event; the contract system archives it, the billing system records it, the client's workflow engine moves on to the next step. None of them needs to know about the others, and participants can be added without touching the signing process.
- Signed events. So that the recipient knows they come from the platform.
- At least once delivery, with an identifier. So that the receiver can discard duplicates.
- Idempotent operations. So that a repeated request does not produce two signatures.
- Explicit states. So that any participant can ask where a process stands.
Orchestration centralizes the process and makes proof easier; choreography distributes coordination and makes integration easier. A good signing design orchestrates the core, where every step must be proven, and choreographs the edges, with signed events, deliveries with an identifier, and idempotent operations.