Subscribing event processors are executed in the same thread as the command component. This implies that the projection will be updated in the same transaction as your aggregate state update (event applied). It is important to note that the projection/view you are maintaining with this subscribing event processors will be
immediately consistent with your command aggregate model. There are some scenarios where this is very valuable, for example
set based validation: https://axoniq.io/blog-overview/set-based-validation. Sharing the same thread with the command side implies that these projections are belonging to the
command side, and you can not separately deploy this event handler/processor. So, it does not scale as the Tracking processor can. Rebuilding/replaying the
subscribing projections is usually not a good idea, as these 'immediate` projections are usually used to validate command decisions.
If you really need to do that, you can easily turn your
subscribing processor to
tracking. It is just a matter of configuration at the end:
# mode: subscribing
Once you are done, you can set it back to subscribing.
Please note that all processors are
tracking by default, and you should consider not changing that, except in some cases where you need immediate consistency as described earlier.