Event sourcing - how to deal with race conditions and http delivery?

Question

I try to understand how I could use event sourcing with a web application. As far as I know event sourcing is about storing db updates in form of events in an event storage. I guess synchronizing the state with the read database is done probably by a daemon, which reads out the latest events from the event storage and performs the changes on the read database.

I have many questions, but I think the best if we talk about an example scenario. For example I want to build a REST service, which has users. I have a constraint, that the user name should be unique. I have an event storage, and I have read db on which I set my constraint. Okay, now I send a POST /users request with an user name which is already stored in the db. First I store the UserCreated event in the event storage, and now what? I can generate a resource id with the event storage I guess, so I can send it back with a 201 created header in an GET /users/{id} link. The client gets that link, clicks on it (probably automatically, or I can even send back a location header), but the read db is not in sync yet, so it will get a 404 not found error... Okay, we can set the client, to wait for a response. I don't get it, on which channels should I send back a response, about the result of the sync? By languages with threads, like java, or by languages with event loop, like nodejs it's okay, I can add events and event handlers, but by languages with processes only, for example php, I have to build some sync daemon with huge memory leaks and find a way to build an event bus upon that. This can be done, but it will be hard and bloody. So after that I will get a correct response, like 500 internal server error, or something like that. So finally I ended up with a corrupted event storage, with an invalid UserCreated event, and I cannot sync it with my read db...

How can I solve these kind of issues?

I still think it is a good approach to store everything in events and add some cache for data reading, but I really don't understand how should I implement this. I think event sourcing can be well suited to websockets + zmq + nodejs, or to similar systems, but not to rest + php... Maybe I lost the point by reading too much about cqrs and event sourcing... :S

Answer 1

As you note, in REST architectures, requests are made to specific resources, like /users/123 or to categories of resources like /users/. When resource actions like adding, deleting, updating /users/124 are performed, there may be clients which are interested in those event. If events are captured, interested clients can be notified in near real-time. This is called an event-based architecture.

Event-based architectures provide an efficient way to keep the state of event-producer and event-consumer clients synchronized with the system instead of the system periodically servicing complete state requests from event-consumer clients (i.e., poll-based clients). Often, both event-driven and poll-driven approaches are used to synchronize clients with the system.

Answer 2

I found the answer here.

Consistency models are a business decision because it directly impacts user experience. An eventually consistent model requires a different user experience than an immediate one, and this is not something you can just “slip in” to your users, or try to emulate. If you’re attempting to emulate immediate consistency in an eventually consistent model, you’re doing something wrong.

Event sourcing requires eventual consistency, while REST can be done with both eventual and immediate consistency. For example you can return a 202 accepted header to indicate eventual consistency. Usually we (at least I) think of REST as I send a POST, and I get back a 201 header with a hypermedia which points to the newly created resource, so I can add more stuff to that resource, modify it, etc... This way I keep my forms small... By eventual consistency, I have to add all of that stuff in a single form, or at least in a single request, unless I don't want to wait for the read - write synchronisation of event sourcing... I think it is a big challange to choose a consistency model for your application, and later it can conflict with the maintenance. For example you intend to add a feature with immediate consistency, but you have already chosen eventual consistency...