EventSourcing.NetCore | Examples and Tutorials of Event Sourcing in .NET | Microservice library

Event-sourced systems by definition have a time lag between an event being stored in an event store, and it is projected to a read model. The lag is always there unless you apply the event synchronously to an in-memory read model when you commit the event to the store. But that approach would limit you to run your service as a single instance, otherwise, you cannot be sure that the in-memory state is synchronized. There are techniques to solve that, but they are rather complex.

As you don't describe the need for you to get the read model data immediately, it's hard to give specific advice, but I have some tips.

1. If you need it for the UI, and the UI needs the new entity state, you can return the entity state as the command handling result, as you already have it. Then, the UI can show the state immediately without executing any queries.

2. Same scenario, but you return a collection of new events to the UI. If the UI bit is built with something like React and Flux, they most probably already have "event sourcing" there (that's what Flux essentially is), and applying those events via their reducers they can update the UI without querying the read model.

3. If you know what read model needs to be in sync (I can't say how many you have), you can propagate the event commit position to the read model as a metadata property, or just as a document property. Then, you can hold the API call (basically wait) until the read model update position property gets equal to or more than the commit position. The drawback is that you can do it for a specific read model only, so your command handler needs to know too much about the read side.

4. Similar to (3) but you check the checkpoint store position. If the checkpoint store is not optimized with batching, it will soon pass over the last event commit position, then you return 200 OK to the caller. It's a bit easier than (3) as it only cares about the subscription checkpoint, not the single read model, but you need access to the checkpoint store.

5. The UI can do the same after they get the command handled, you need to return the commit position of the last event, and they query and wait.

I've seen all of the above working in production, but my preferred solutions are (1) and (2).

To make any of those work, your command service needs to return a sophisticated result to the caller (API, or beyond) as I've done in Eventuous.