Publié par : yoannr | 22 août 2012

Learning EDA/CQRS/ES- denormalizing events from my bounded context


One tough problem that has been on  my arms for the last month is how to deal with the ordering of events within on single bc and between different bcs communicating together. I am using RabbitMq and learning the abc of messaging with it.  I might missing some magic ( who said basic? 🙂 ) tricks, and this is a post to order a bit more my own thoughts.

My application is composed of different bounded contexts:

  • Schedule
  • Contractor
  • Control
  • Accounting

Let’s assume Schedule generate an event  InterventionScheduled :

This event goes into the event store and then get publish eventually. That goes fine , usually some denormalizer waits in the dark to get the event and denormalize it into the read database.

My problem arose when two events are fired that should have order between them. Let’s call them e1 and e2. For sake of clarity e1 should be denormalized before e2.

public class EventProjection : IEventHandler<e1>,
                               IEventHandler<e2>;
{
   public void Handle(e1 @event)
   {
      //Denormalize e1 in the database
   }
   public void Handle(e2 @event)
   {
      //Denormalize e1 in the database
   }
}

First attempt : We have two queues queue_e1, queue_e2. The two events are arriving very fast and so are present into those two queues at the same time.

Projection might get the event in queue_e2 and thus denormalize e2 before getting to e1. This can lead to problems , error, inconsistent state and so on.. not so good.. or so it appears at first glance.

second attempt : What if I had only one queue per bounded context, this way I could guarantee the order of processing of my events.

public class ProjectionHandlerService : ProjectionHandlerServiceBase</pre>
{
   public override void Subscribe(IBus bus)
   {
      bus.Subscribe<e1>(Execute);
      bus.Subscribe<e2>(Execute);
   }
}
<pre>

This does not resolve our issue though the events are now in the correct order. The subscribing to event to a single queue creates a round robin cycle.

I could create a queue per projection and then directly bind my projection to eat the event coming from this queue.  but that means that, the knowledge of my projection are leaking into the messaging system.

So back to square one, what is the real business impact of having different queues for each event. I would say that the percentage of chance of having two events not following the same order should low enough.  Not all events have to behave this way. Most of them are simple events not having anything to do with one another, or they might but their  creation are spread upon hours, not milliseconds.

I always have the possibility to know when there is a problem and solve it in a casual way. So I will come back to my first attempt with easynetQ which was working fine, and deal  with errors when (if ?)  they come…


		
Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

Catégories

%d blogueurs aiment cette page :