Skip to content

Explicit Event Store Subscriptions

Chronicle supports explicit subscriptions — manual registration of subscriptions between event stores using the Subscriptions API. When you configure a subscription explicitly, you control:

  • Which event types are forwarded
  • Subscription lifecycle and management
  • The subscription identifier for reference and cleanup

Explicit subscriptions are ideal when:

  • You need fine-grained control over which event types are forwarded
  • The source service’s event types are not in a shared NuGet package
  • You want to dynamically create or remove subscriptions
  • Events come from a legacy or external system

Use the Subscriptions property on IEventStore to subscribe:

using Cratis.Chronicle;
using Cratis.Chronicle.Events;
[EventType]
public record SubscriptionsExplicitShipmentDispatched(string OrderId);
public static class SubscriptionsExplicitBasic
{
public static Task Run(IEventStore eventStore) =>
eventStore.Subscriptions.Subscribe(
"orders-from-fulfillment",
"fulfillment-service",
builder => builder.WithEventType<SubscriptionsExplicitShipmentDispatched>());
}

View C# snippet source on GitHub

The three arguments are:

ArgumentDescription
Subscription IDA stable, unique string that identifies this subscription within the target event store
Source event storeThe name of the event store whose outbox to subscribe to
Configuration callbackOptional — filters which event types to forward

The subscription ID must be unique within the target event store. It serves as the persistent identifier for the subscription on the kernel side. If you call Subscribe with the same ID, the kernel treats it as idempotent — no duplicate subscription is created.

A typical naming convention:

using Cratis.Chronicle;
using Cratis.Chronicle.Events;
[EventType]
public record SubscriptionsExplicitStockAdjusted(string ItemId, int Delta);
public static class SubscriptionsExplicitNamingConvention
{
public static async Task Run(IEventStore eventStore)
{
// subscription-id format: {target}-from-{source}
await eventStore.Subscriptions.Subscribe(
"orders-from-fulfillment",
"fulfillment-service",
builder => builder.WithEventType<SubscriptionsExplicitShipmentDispatched>());
await eventStore.Subscriptions.Subscribe(
"inventory-from-warehouse",
"warehouse-service",
builder => builder.WithEventType<SubscriptionsExplicitStockAdjusted>());
}
}

View C# snippet source on GitHub

Without a configuration callback, the subscription forwards every event type your client knows about when it registers the subscription — in practice, the contract types your application references. Source events of a type your client does not have are not forwarded. Use WithEventType<T>() to limit the subscription to specific types:

using Cratis.Chronicle;
using Cratis.Chronicle.Events;
[EventType]
public record SubscriptionsExplicitStockReserved(string ItemId, int Quantity);
public static class SubscriptionsExplicitFiltering
{
public static Task Run(IEventStore eventStore) =>
eventStore.Subscriptions.Subscribe(
"inventory-updates",
"warehouse-service",
builder => builder
.WithEventType<SubscriptionsExplicitStockAdjusted>()
.WithEventType<SubscriptionsExplicitStockReserved>());
}

View C# snippet source on GitHub

To subscribe without filtering — every event type your client knows about — omit the configuration callback entirely:

using Cratis.Chronicle;
public static class SubscriptionsExplicitNoFilter
{
public static Task Run(IEventStore eventStore) =>
// All events from fulfillment-service outbox will be forwarded
eventStore.Subscriptions.Subscribe(
"all-fulfillment-events",
"fulfillment-service");
}

View C# snippet source on GitHub

Pin the Generation Your Application Understands

Section titled “Pin the Generation Your Application Understands”

Opt in per subscription with WithGenerationDelivery(EventGenerationDelivery.Pinned). A generic WithEventType<T>() pins the generation declared by that event type. An identifier-only declaration resolves to the single generation your client knows; use the identifier-and-generation overload when that declaration is ambiguous or the type has no CLR representation.

using Cratis.Chronicle;
using Cratis.Chronicle.Events;
using Cratis.Chronicle.Observation;
[EventType("subscription-stock-adjusted", generation: 2)]
[Public]
public record SubscriptionStockAdjusted(int Quantity);
public static class PinnedInventorySubscription
{
public static Task Register(IEventStore eventStore) =>
eventStore.Subscriptions.Subscribe(
"inventory-updates",
"warehouse-service",
builder => builder
.WithGenerationDelivery(EventGenerationDelivery.Pinned)
.WithEventType<SubscriptionStockAdjusted>());
public static Task RegisterByIdentifier(IEventStore eventStore) =>
eventStore.Subscriptions.Subscribe(
"inventory-updates",
"warehouse-service",
builder => builder
.WithGenerationDelivery(EventGenerationDelivery.Pinned)
.WithEventType("subscription-stock-adjusted", 2));
}

View C# snippet source on GitHub

Register the exact generation in both the source and target event stores before subscribing. The kernel validates the entire pinned registration request before changing any definitions. An unavailable generation or conflicting generations for the same event type fails explicitly; a readiness timeout cannot substitute for this validation. Upgrade every kernel silo before opting in.

The source outbox observer selects and releases the pin on live, catch-up, replay, and retry delivery. The target inbox appends that delivered generation, not the source event’s original append generation. Protected values are released with the selected source schema and protected again by the target append; an erased target subject’s key is never reinstated. If a generation disappears from the target’s registration later, forwarding fails without appending that event or advancing past it.

Pins and the delivery policy survive restarts, reconnects, and identical registrations. Register the same subscription ID with a deliberately changed generation or policy to update it; reconciliation rebinds the source observer without an unsubscribe gap. GetAll() exposes the policy in GenerationDelivery and exact generations in EventTypePins, alongside the existing id-only EventTypes.

The default remains Compatibility: existing subscriptions still send generation 1 in their registration and retain their existing forwarding behavior. The global client generation-delivery option does not opt subscriptions in.

Events forwarded via an explicit subscription are placed into the inbox sequence for the source event store. Access inbox events through any observer (reactor, projection, reducer):

using Cratis.Chronicle.Events;
using Cratis.Chronicle.Reactors;
[EventType]
public record SubscriptionsExplicitOrderPlaced(Guid OrderId, decimal Amount);
public class SubscriptionsExplicitIncomingOrdersReactor : IReactor
{
public Task OrderPlaced(SubscriptionsExplicitOrderPlaced @event, EventContext context)
=> HandleIncomingOrderAsync(@event.OrderId, @event.Amount);
Task HandleIncomingOrderAsync(Guid id, decimal amount) => Task.CompletedTask;
}

View C# snippet source on GitHub

The kernel automatically routes incoming events to the appropriate inbox-{sourceEventStore} event sequence. You do not need to reference the subscription ID when observing the events.

using Cratis.Chronicle;
public static class SubscriptionsExplicitUnsubscribe
{
public static Task Run(IEventStore eventStore) =>
eventStore.Subscriptions.Unsubscribe("orders-from-fulfillment");
}

View C# snippet source on GitHub

Calling Unsubscribe with the subscription ID:

  • Stops event forwarding from the source outbox
  • Removes the persistent subscription definition from the kernel
  • Existing inbox events are not deleted — they remain available for observation

Once removed, no new events are forwarded to the inbox. If you later recreate the subscription with the same ID, forwarding resumes from that point forward.

Subscriptions are identified by their subscription ID. Calling Subscribe with the same ID more than once is safe — if the subscription already exists, no duplicate subscription is created.

This makes it safe to register all subscriptions at application startup without checking if they already exist:

using Cratis.Chronicle;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
public static class SubscriptionsExplicitStartupRegistration
{
public static async Task Configure(string[] args)
{
var builder = Host.CreateApplicationBuilder(args);
builder.AddCratisChronicle(options => options.EventStore = "Quickstart");
// Safe to call on every application startup
var app = builder.Build();
var eventStore = app.Services.GetRequiredService<IEventStore>();
await eventStore.Subscriptions.Subscribe(
"orders-from-fulfillment",
"fulfillment-service",
builder => builder.WithEventType<SubscriptionsExplicitShipmentDispatched>());
await eventStore.Subscriptions.Subscribe(
"inventory-from-warehouse",
"warehouse-service",
builder => builder.WithEventType<SubscriptionsExplicitStockAdjusted>());
await app.RunAsync();
}
}

View C# snippet source on GitHub

Identical registrations leave existing definitions unchanged. A deliberately changed registration updates the same subscription, including its exact pins and delivery policy when you opt in.

Explicit subscriptions are kernel-managed and persistent:

  • Created when you call Subscribe, stored on the kernel, and assigned a subscription ID
  • Persisted — survive client disconnections and kernel restarts
  • Re-established automatically when the kernel starts, even if the client is not connected
  • Removed only when you explicitly call Unsubscribe

A common pattern is to register all subscriptions once during application startup:

using Cratis.Chronicle;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
public static class SubscriptionsExplicitTypicalPattern
{
public static async Task RegisterSubscriptions(IEventStore eventStore)
{
await eventStore.Subscriptions.Subscribe(
"orders-from-fulfillment",
"fulfillment-service",
builder => builder.WithEventType<SubscriptionsExplicitShipmentDispatched>());
await eventStore.Subscriptions.Subscribe(
"inventory-updates",
"warehouse-service",
builder => builder
.WithEventType<SubscriptionsExplicitStockAdjusted>()
.WithEventType<SubscriptionsExplicitStockReserved>());
}
public static async Task Configure(string[] args)
{
var hostBuilder = Host.CreateApplicationBuilder(args);
hostBuilder.AddCratisChronicle(options => options.EventStore = "Quickstart");
var app = hostBuilder.Build();
var eventStore = app.Services.GetRequiredService<IEventStore>();
await RegisterSubscriptions(eventStore);
await app.RunAsync();
}
}

View C# snippet source on GitHub

Use explicit subscriptions when:

  • You need fine-grained control over which event types are forwarded
  • Event types are not published in a shared NuGet package
  • You need to dynamically create or remove subscriptions at runtime
  • The subscription relationship is consuming-service-specific

Use implicit subscriptions when:

  • Event types are published in a shared NuGet package with [EventStore] attributes
  • All events from a source should be automatically forwarded
  • You prefer zero configuration and automatic routing