Jump to: navigation, search

Zaqar/specs/use-cases/3

< Zaqar
Revision as of 18:42, 7 August 2014 by Malini (talk | contribs) (Malini moved page Marconi/specs/use-cases/3 to Zaqar/specs/use-cases/3: Project Rename)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Marconi: Use Case 3

Publish events to any number of subscribers.

Characteristic Information

Goal in Context
Preconditions
Success End Condition
Failed End Condition
Primary Actor
Trigger

Scope

This use case only covers pub-sub within a single application domain. Publishing events to 3rd-party systems, including via web hooks, email, mobile messaging services, etc., is out of scope for this project. Such notification bridges are best implemented as complementary services.

Main Sequence

1. Publisher signs event and submits it to Service

2. Service acknowledges event and guarantees its durability

3. Subscriber retrieves event from Service

4. Subscriber verifies authenticity of the event

5. Subscriber processes event

6. Subscriber loops to (3)

Variations

2a. Service is unable to persist event in a durable manner: Service returns error status and information to Publisher; Publisher may choose to retry the request or simply log the failure and carry on, depending on the nature of the error received.

2b. Publisher may specify durability tolerance: If an event is ephemeral and Publisher is willing to trade durability for performance, Publisher may provide a hint to Service as part of the submission process.

3a. More than one event has been enqueued: Subscriber retrieves up to min(50, n), where n is specified by the Subscriber in each request to Service.

3b. No events are available: Service returns "no content" status code, and Subscriber must try again after some delay.

3c. Subscriber must distinguish a particular event stream: Publisher tags events, and Subscriber requests that the Service filter events by the specified tags (negotiated out-of-band between Publisher and Subscriber).

4a. Event's signature is invalid: Subscriber ignores the bad event by skipping the next step (5).

6a. More than min(50, n) messages are enqueued, or Publisher submits events faster than they can be consumed: Subscribers loop until all events have been processed. Publisher may need to increase TTL for events so that Subscribers are able to keep up.

Related Information

  • More than one subscriber may receive the same events IFF filtering on the same set of tags. To facilitate point-to-point or RPC-style communications, each subscriber must filter on a unique set of tags.
  • All event submissions and retrievals are noted in the audit river, and observable by polling the same.
  • Components and collectors can namespace events via tagging.
  • Publishers, subscribers and auditors may request message bus metrics, optionally filtering by one or more tags. This might be used, for example, to dynamically adjust event TTLs.