| title | Persistence |
|---|---|
| description | Where workflow state is stored, and the persistence adapters maintained with the bus. |
A persistence stores the state of running workflows between messages, and messages sent with delayed delivery until they're due. This page lists the persistence adapters maintained with the bus. A service that uses neither doesn't need one.
By default the bus keeps workflow state and scheduled messages in memory, with InMemoryPersistence. That's only for development: they're lost when the process stops, and aren't shared between instances of a service. Because a durable persistence keeps the state in a database, any instance can handle a workflow's next message, services can be scaled in and out freely, and a restart loses nothing.
Every persistence uses optimistic concurrency: saving fails if another handler saved the same workflow instance since it was read, and the message is retried with the latest state.
Postgres, MongoDB (on a replica set) and InMemoryPersistence can also handle each message in a transaction that covers its workflow state and the messages its handlers send, with the transactional outbox.
A scheduled message is only deleted from the persistence once it's sent, so a broker outage pauses scheduled sends rather than dropping them. Every bus that shares a persistence's scheduled messages, in any process, must use the same broker, since any started bus sends them through its own transport (see delayed delivery).
A persistence instance can be shared by several buses in one process. Each bus converts the state with its own serializer and message types, and the persistence is disposed when the last bus that uses it is disposed.
- Transports
Persistencein the API reference