Persistence Architecture
Persistence is flexible. Administrators can tailor various aspects of persistence to meet the needs of applications.
Storage, Replication, and Fault Tolerance
Persistence services store message data in process memory, avoiding latency associated with disk I/O.
Replication of data across a cluster of persistence services protects against hardware or network failures on a small scale. (However, this replication scheme cannot guarantee delivery after catastrophic failures.)
Latency
Using persistence for delivery assurance is consistent with high-speed message delivery with low latency. Delivery assurance operates alongside regular direct-path delivery. Transports carry messages directly from publishers to subscribers without an intermediary hop through a persistence service, which would add message latency. Separate transports carry messages from publishers to standard durables in a store in the persistence services, which retain them for as long as subscribers might need to recover them.
In contrast, using persistence to apportion message streams or for last-value availability emphasizes throughput rather than the lowest latency. Delivery through durables replaces direct-path delivery. The persistence service is an intermediary hop, which adds message latency.
Meanwhile, a message broker emphasizes the convenience of a well-known pattern and minimal configuration, at the cost of added latency.
Wide-area stores involve the inherent latency of a WAN.
Publisher Quality of Service
For each store, administrators can balance appropriately between performance requirements and the need to confirm message replication.
Subscriber Acknowledgment
Within application programs, subscribers can acknowledge message delivery automatically or explicitly.
Administrators can configure durables to receive individual acknowledgements synchronously, or in asynchronous batches.
Durable Creation
Administrators can arrange for dynamic durables, which applications create as needed. Dynamic durables require only little administrative configuration. Programmers take responsibility for the number of durables and their names.
Administrators can define static durables in the realm. Static durables require more administrative configuration and greater coordination between programmers and administrators. Administrators control the number of durables and their names.