Subscriptions notes

subscriptions.md

Connecting

• Uri format
  • Single node tcp://user:password@myserver:11234
  • DNS discover://user:password@myserver:1234
  • Simplest possible eventstoreConnection.Create(Uri uri)
• ConnectionSettings vs Connection Strings
  • Settings = fluent API (show example)
  • Connection string = Newer, familiar format, can store in config, probably better?
    • "ConnectTo=tcp://admin:changeit@localhost:1113; HeartBeatTimeout=500"
  • Important options
    • GossipSeeds

Subscriptions

• Subscriptions let the server push new events to the client
  • Let you react to changes with low latency
  • Can subscribe to specific streams, or to all events (for volatile/catchup)

Volatile

• Start receiving events from the moment you subscribe, until the moment the subscription stops
• If there were events in the stream beforehand you will not see them
• Reconnecting may miss events, but the subscription will recover
• "I only care about the latest events and don't care if we miss some"
  • Non-critical notifications
  • Stats for current session
• Demo?

Catch up subscriptions

• Let you say "give me all events since point X"
• Great for populating cqrs readmodels
• Ensure we don't miss any events, even after a reconnection
• Possible to build yourself, but we handle the tricky parts 2 Phases
  • Catch Up (internally uses Regular read calls to give you events up to current head of the stream).
  • LiveProcessingStarted callback -> finished catching up, your view of the world is up to date now
  • Live events pushed (uses a volatile subscription internally)
• It is your job to maintain a checkpoint e.OriginalEvent.EventNumber or e.OriginalPosition
• If possible, do this atomically with your work (sql transaction etc) to get exactly once delivery

EventAppeared(e) {
	Start Transaction
		Update customers table
		Update checkpoint table
  Commit Transaction 
}

• Code
• Demo?

Persistent subscriptions

• Competing consumers pattern
  • Multiple clients connect to a single stream, receive a portion of the events each
  • Each event will only be seen by one consumer, unless errors
  • Server keeps track of which events have been delivered, successfully processed
  • Clients can join and leave the group at will, server will handle appropriately
• Useful for computationally intensive tasks where you want to parallelise subscribers
• Strategies
  • RoundRobin Attempts to distribute evenly across clients
  • DispatchToSingle Picks a single subscriber, if its queue fills, move to next
  • Pinned Same streamId -> Same Client
• Show code
  • Creating subscription group
  • Connecting to it + handling events
  • Mention explicit Acknowledge or Fail
• Code
• Demo?

Things to check

• Do volatile subscriptions recover after a disconnect in the same way as catchup?
• Default strategy for competing consumers
• Pinned says a particular stream goes to a particular subscriber - You can't subscribe to multiple streams? Does this apply to linked events?