I think I get the gist from your question @Ashwini_Kumar, but I would like to ask you to edit the question to separate it out a little more in manageable chunks. This isn’t only beneficial for me to be certain I am answering your question correctly, but also for others who might be facing the same issue you are facing right now.
Nonetheless, let me give it a try and me parse out the first question in your text:
…as far as I understand all the event handling component will receive events in the order persisted in the event store so this should ensure that whichever event got persisted first will have their event handler getting them first. Is this understanding correct?
This understanding is correct. The insert order of your events is maintained as the order in which they are handled. There is, however, a notion of parallelizing the event handling load which has some impact. Luckily you are moving into this point with your following question:
…if we have 2 segment and 2 threads per TEP instance is there a guarantee that the event that got persisted first will complete processing first and then only the next event…
Having 2 segments in essence means you have split your event stream in two. You however have the power to decide how the events are “sequenced” to each of these portions of the stream. Axon does this through means of the SequencingPolicy, which is invoked every time prior to entering your Event Handling functions and used to check whether the value matches the segment that thread is controlling.
If it does not match, the event will simply be disregarded by that exact segment. If it does match, it will, as you might have guessed, be handled by that segment.
By default the SequencingPolicy is configured as the SequentialPerAggregatePolicy. This implementation will use the aggregate identifier to decide if an event belongs to a given segment yes/no. Doing so, ensure that all events originating from the same Aggregate instance (as defined through the aggregate identifier) will be handled in the order they have been inserted in your event store.
What you point out is that you are using the EventGateway#publish method, however. Note that when using this approach to publishing events, you are not publishing so called “domain events”. It is the domain event that contains an aggregate identifier (since it is published from inside your domain model). As such, the default SequentialPerAggregatePolicy has not aggregate identifier to guarantee this ordering through. This means that by using this means of publishing in conjunction with the configured SequencingPolicy, the event handling order between two (or more) different segments on a TrackingEventProcessor is unclear.
You can, however, provide your own implementation of the SequencingPolicy, which uses a different value to deduce in what segment an event should land up. Whether there is such a value in your domain, is hard to deduce for me from the outside. You could think about a correlation/trace/session identifier in the meta data of the EventMessage which is identical among the events which should be handled in order. Or perhaps you have a domain-specific identifier (like a user id) that can be used to this end. Whichever it is, you will need to provide a custom SequencingPolicy which takes this other value into account to deduce which segment is in control of what event.
Lastly, you can indeed simply use a single segment for the TrackingEventProcessor too. This effectively means all events belong in the same portion of the event stream, as it is comprised of everything. Note that the thread count does not matter in this case, as a TrackingEventProcessor can only process events if it has a claim on a segment. Thus with one segment, only a single thread would ever perform any work.
Hoping to have clarified your options sufficiently, @Ashwini_Kumar.