Subscription concurrency

[slashdotdash]

Allow multiple subscribers to connect to a single subscription, allowing concurrent event processing and load balancing between all connected subscriber processes.

Connecting more than one subscriber to a subscription will mean that event handling order is no longer guaranteed since events will be processed concurrently. However you can provide a partition_by function to return a partition key from an event. This will guarantee events for the same key will be handled in order. You might use an aggregate's identity as the partition key to have events for each aggregate instance ordered.

Example usage

{:ok, subscription} =
  EventStore.subscribe_to_all_streams(
    "example",
    subscriber1,
    concurrency_limit: 2
  )

{:ok, ^subscription} =
  EventStore.subscribe_to_all_streams(
    "example",
    subscriber2,
    concurrency_limit: 2
  )

{:error, :too_many_subscribers} =
  EventStore.subscribe_to_all_streams("example", subscriber3, concurrency_limit: 2)

See the Subscription concurrency section in the subscription guide for more detail.

Fixes #124.

[ababushkin]

👍

[ababushkin]

Heroic effort! This is going to bring some exciting capabilities to commanded.