At the heart of the Dolittle runtime sits the concept of Event Horizon. Event horizon is the mechanism for a microservice to give Consent for another microservice to Subscribe to its Public Stream and receive Public Events.
ProdEventLog[(Event Log)] -->|Public events| PublicFilter[Public Filter]
PublicFilter -->|matches go into| PublicStream[(Public Stream)]
Consent(((Consent))) -->|gives access to| PublicStream
Subscription -->|stores| ConEventLog[(Scoped Event Log)]
Subscription -->|asks for events| Consent
Once an event moves past the event horizon, the producer will no longer see it. The producer doesn’t know or care, what happens with an event after it has gone past the event horizon.
A consumer is a tenant that subscribes to a partition in one of the Producer’s public streams. The events coming from the producer will be stored into a Scoped Event Log in the consumer’s event store. This way even if the producer would get removed or deprecated, the produced events are still saved in the consumer. To process events from a scoped event log you need scoped event handlers & filters.
The consumer sets up the subscription and will keep asking the producer for events. The producers Runtime will check whether it has a consent for that specific subscription and will only allow events to flow if that consent exists. If the producer goes offline or doesn’t consent, the consumer will keep retrying.
This is a simplified structure of a
Subscription in the consumer.
// the producers microservice, tenant, public stream and partition
// the consumers scoped event log
Multiple subscriptions to same scopeIf multiple subscriptions route to the same scoped event log, the ordering of the events cannot be guaranteed. There is no way to know in which order the subscriber receives the events from multiple producers as they are all independent of each other.
We’re working on a solution for event migration strategies using Generations. As of now there is no mechanism for dealing with generations, so they are best left alone. Extra caution should be paid to changing public events so as not to break other microservices consuming those events.