Note that services can subscribe to two kinds of topics:
Delivery of messages for each subscription is always carried out by a single server, called a delivery server for that subscription. This ensures correct message ordering - if there are multiple servers in a Zato cluster each receiving messages ultimately destined for the subscription, they will be forwarded to that subscription's delivery server first. For in-RAM messages, they are kept in the delivery server's RAM.
Messages can be sent on a notify or pull basis. The former means that Zato itself will be invoking the endpoint with new messages whereas pull means that Zato will queue messages up and the recipient itself will periodically read the contents of its queue. Regardless of the delivery type, messages can be sent one-by-one or in batches of a pre-configured size.
Delivery of a message can be repeated up to a configured number of times, with a sleep time in between them, configurable depending on what kind of error was encountered - a TCP socket-level one or a different one.
For each type of an endpoint, this endpoint type's specific options can be provided - for instance, the endpoint in the screenshot above is a REST one so an HTTP method can be specified that should be used to deliver messages with.
Each endpoint may subscribe to topics multiple types and each time it is given a new subscription key - this is a secret that must be known only to the participant to whom it was issued.