Imagine a situation where a read model is updated by events originating from within the bounded context, and some that originate from another bounded context. The question is: If I need to do an event-replay to rebuild that Read Model from scratch, should I rely on the external bounded context to replay its respective events properly OR should each bounded context store relevant events that originate from outside?
The tradeoffs I see are:
If I store every external event I receive (subscribe to) then an erroneous flood of events from outside could hammer my event log and cause DynamoDB ProvisionedThroughputExceededException errors. I would be powerless to stop it, short of pushing a circuit breaker.
If I don't store every external event I rely upon then I have to trust replay from the external bounded context
Here's an example scenario, Reservations should not book more people than a plan can hold, yet Scheduling is in charge of which aircraft types are on each flight. In order to maintain a correct count of seat availability I need to consume an event like ScheduledFlightAdded from Scheduling to set Item.SeatsAvailable to its initial value in my read model in DynamoDB (i.e. 318 for a Boeing 787-10). Then every reservation I sell in Reservations can decrement that number. If I need to rebuild this read model, Scheduling's local events will not be enough. I'll have to request replay from Reservations. If instead I've stored those events, then no problem.
So, the principle would be bounded contexts should store externally generated events they're concerned with, or no?
My gut tells me you need to save all external events you're concerned with, otherwise you might not be able to properly recreate the state of your read models. Perhaps this gives value to the idea that each StoreConstruct should have its own table. You could then have a Store for ExternalEvents thereby not risking adverse effects on your main event store? :thinking_face:
Spoke with @michaellperry today and his response (summarizing) is: Yes we want to cache events from outside so we're not temporally coupled to another service (waiting).
Imagine a situation where a read model is updated by events originating from within the bounded context, and some that originate from another bounded context. The question is: If I need to do an event-replay to rebuild that Read Model from scratch, should I rely on the external bounded context to replay its respective events properly OR should each bounded context store relevant events that originate from outside?
The tradeoffs I see are:
ProvisionedThroughputExceededException
errors. I would be powerless to stop it, short of pushing a circuit breaker.Here's an example scenario, Reservations should not book more people than a plan can hold, yet Scheduling is in charge of which aircraft types are on each flight. In order to maintain a correct count of seat availability I need to consume an event like
ScheduledFlightAdded
from Scheduling to setItem.SeatsAvailable
to its initial value in my read model in DynamoDB (i.e. 318 for a Boeing 787-10). Then every reservation I sell in Reservations can decrement that number. If I need to rebuild this read model, Scheduling's local events will not be enough. I'll have to request replay from Reservations. If instead I've stored those events, then no problem.So, the principle would be bounded contexts should store externally generated events they're concerned with, or no?
My gut tells me you need to save all external events you're concerned with, otherwise you might not be able to properly recreate the state of your read models. Perhaps this gives value to the idea that each
StoreConstruct
should have its own table. You could then have a Store for ExternalEvents thereby not risking adverse effects on your main event store? :thinking_face: