-1

I am new to Event sourcing concept so there are a couple of moments I don't understand. One of them is how to handle following scenario:

I've got 2 instances of a service. Both of them listen to a event queue. There are two messages: CreateUser and UpdateUser. First instance picks up CreateUser and second instance picks up UpdateUser. For some reason second instance will handle its command quicker but there will be no User to update, since it was not created.

What am I getting wrong here?

Alexander Capone
  • 528
  • 3
  • 16
  • 1
    First, I would clarify your question. I'm assuming you are talking about commands here. Еvents are not commands, commands are not events. CreateUser sounds like a command. UserCreated - an event. – Roman Eremin Dec 05 '18 at 15:32
  • I am speaking with a lack of propper context (your question does not put much of that over the table) but the first thing it comes to my head is: UpdateUser message should never even exist until CreateUser finish its work... – jlvaquero Dec 07 '18 at 06:59
  • @AlexanderCapone Event Sourcing is not about instances picking up messages. You're probably confusing with message queue/bus. You should also make it clearer why you need 2 instances of the same service. – guillaume31 Dec 17 '18 at 12:43

2 Answers2

1

What am I getting wrong here?

Review: Race Conditions Don't Exist

A microsecond difference in timing shouldn’t make a difference to core business behaviors.

In other words, what you want is logic such that the order of the messages doesn't change the final result, and a first writer wins policy (aka compare-and-swap), so that when you have two processes trying to update the same resource, the loser of the data race has to start over.

As a general rule, events should be understood to support multiple observers - all subscribers get to see all events. So a queue with competing consumers isn't the usual approach unless you are trying to distribute a specific subscriber across multiple processes.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91
-1

You do not have a concurrency issue you can solve. This totally runs down to either using bad tools or not reading the documentation.

Both of them listen to a event queue.

And that queue should support that. Example are azure queues, where I Can listen AND TELL THE QUEUE not to show the event to anyone else for X seconds (which is enough for me to decide whether i handled it or not). If I do not answer -> event is reinserted after that time. If I kill it first, there is no concurrency.

So, you need a backend queue that can handle this.

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • Okay, if we are speaking about ServiceBus queues, for example. My service that listens to that queue has 2 instances. While first instance is working on 'create' event, second instance will get the 'update' event and fail to execute this command, as it will be not valid. Right? – Alexander Capone Dec 05 '18 at 12:34
  • Your comments are not adding too much of a value, to be honest. Would you please recommend how to make, for example, servicebus queue make sure that its items will be handled by the same service instance? – Alexander Capone Dec 05 '18 at 14:15
  • 1
    Yeah. Hire an architect - your services are not designed with reality in mind. Better? – TomTom Dec 05 '18 at 14:18
  • I can say that we will probably not hire you if you were an architect, thanks, bye. – Alexander Capone Dec 05 '18 at 14:37
  • That is ok. See, I am full busy working for years now. I dont ever get hired. – TomTom Dec 05 '18 at 14:58