These are chat archives for RBMHTechnology/eventuate

Aug 2016
Alexander Semenov
Aug 05 2016 04:08
@magro yes, they can
Alexander Semenov
Aug 05 2016 04:13
thank you
Narayan Kumar
Aug 05 2016 08:07
@krasserm I have a question regarding event replay. In one of my project, based on micro services , I am horizontally scaling each micro service and integrating with AWS Load Balancer. All the services are based on eventuate technology. The question is regarding a particular working of how to replay events. Consider this example. I have multiple account services running on different ECS instance. I am storing OTP 'in-memory' while handling the event. So there is a possibility that when a user is registering the OTP is sent and stored by instance A and when the user is verified the request for verifying goes on to instance B but the actual OTP for that user was on instance A and will not be found on instance B. So I want to know how can we properly replay the events so that the OTP for a user is available on any instance.
Aug 05 2016 12:21
This message was deleted
Aug 05 2016 12:57

I was going to say to @knoldernarayan that use Conditional Requests but this works only if I write and read (conditional request) to the same endpoint, doesn't? Because timestamps are local to an endpoint?
However, when you ask

how can we properly replay the events so that the OTP for a user is available on any instance.

I think that events are currently being property replicated asynchronously, so you'll never see a global state shared between all the instances (this is the way Eventuate/Causal Consistency works).

Martin Grotzke
Aug 05 2016 14:02
@gabrielgiussi @knoldernarayan From my understanding there would have to be a OneTimePasswordGenerated event that is replicated. When the user wants to login the (replicated) system needs to verify the OTP, for which it needs the OneTimePasswordGenerated event. For this (processing the "VerifyOTP" command) the system would have to use a ConditionalRequest(timestamp, VerifyOTP(otp)) including the vector timestamp from the OneTimePasswordGenerated event. Therefore the user would have not only to provide the OTP but also the vector timestamp. Assuming the system sends a link for the next login to the user (not only the OTP) this link could contain the additionally needed information (everything somehow hashed/encrypted of course). Alternatively (from a technical perspective) the OTP presented to the user could be "$otp:$timestamp" so that both parts that are needed for the verification are available. From a usability perspective this would not be nice because the OTP as presented to the user would be rather long.