Event sourcing: Write event before or after updating the model

Posted by Magnus on Stack Overflow See other posts from Stack Overflow or by Magnus
Published on 2012-10-15T21:33:37Z Indexed on 2012/10/15 21:36 UTC
Read the original article Hit count: 320

Filed under:
|

I'm reasoning about event sourcing and often I arrive at a chicken and egg problem. Would be grateful for some hints on how to reason around this.

If I execute all I/O-bound processing async (ie writing to the event log) then how do I handle, or sometimes even detect, failures?

I'm using Akka Actors so processing is sequential for each event/message. I do not have any database at this time, instead I would persist all the events in an event log and then keep an aggregated state of all the events in a model stored in memory. Queries are all against this model, you can consider it to be a cache.

Example

Creating a new user:

  1. Validate that the user does not exist in model
  2. Persist event to journal
  3. Update model (in memory)

If step 3 breaks I still have persisted my event so I can replay it at a later date. If step 2 breaks I can handle that as well gracefully.

This is fine, but since step 2 is I/O-bound I figured that I should do I/O in a separate actor to free up the first actor for queries:

Updating a user while allowing queries (A0 = Front end/GUI actor, A1 = Processor Actor, A2 = IO-actor, E = event bus).

  1. (A0->E->A1) Event is published to update user 'U1'. Validate that the user 'U1' exists in model
  2. (A1->A2) Persist event to journal (separate actor)
  3. (A0->E->A1->A0) Query for user 'U1' profile
  4. (A2->A1) Event is now persisted continue to update model
  5. (A0->E->A1->A0) Query for user 'U1' profile (now returns fresh data)

This is appealing since queries can be processed while I/O-is churning along at it's own pace.

But now I can cause myself all kinds of problems where I could have two incompatible commands (delete and then update) be persisted to the event log and crash on me when replayed up at a later date, since I do the validation before persisting the event and then update the model.

My aim is to have a simple reasoning around my model (since Actor processes messages sequentially single threaded) but not be waiting for I/O-bound updates when Querying. I get the feeling I'm modeling a database which in itself is might be a problem.

If things are unclear please write a comment.

© Stack Overflow or respective owner

Related posts about cqrs

  • CQRS at Jax Code Camp 2012

    as seen on ASP.net Weblogs - Search for 'ASP.net Weblogs'
    Continuing my CQRS world tour...I gave my CQRS presentation at the Jax Code Camp 2012 this past Saturday.  It was a great crowd with lots of representation from the wicked smart engineers at Feature[23] and others from the Jacksonville developer community. If you'd like to take a… >>> More

  • CQRS without using others patterns

    as seen on Programmers - Search for 'Programmers'
    I would like to explain CQRS to my team of developers. I just can't figure out how to explain it in the simplest way so they can implement the pattern rapidly without any others frameworks. I've read a lot of resources including video and articles but I don't find how to implement CQRS without using… >>> More

  • Domain queries in CQRS

    as seen on Stack Overflow - Search for 'Stack Overflow'
    We are trying out CQRS. We have a validation situation where a CustomerService (domain service) needs to know whether or not a Customer exists. Customers are unique by their email address. Our Customer repository (a generic repository) only has Get(id) and Add(customer). How should the CustomerService… >>> More

  • CQRS - The query side

    as seen on Stack Overflow - Search for 'Stack Overflow'
    A lot of the blogsphere articles related to CQRS (command query repsonsibility) seperation seem to imply that all screens/viewmodels are flat. e.g. Name, Age, Location Of Birth etc.. and thus the suggestion that implementation wise we stick them into fast read source etc.. single table per view mySQL… >>> More

  • CQRS event versioning

    as seen on Stack Overflow - Search for 'Stack Overflow'
    Versioning If your events changes you would create a new version of that event, and keep the old ones. To keep your domain code form being bloated with handling of all versions of events you would basically introduce a component that converts your events from previous to newer versions, and then… >>> More

Related posts about event-sourcing