1

I'm developing a microservice with CQRS and Event Sourcing. When an event is saved to the event store, the service currently also saves the updated aggregate root as a JSON object in a separate table. So far I have separated the write model from the read model (though not in separate data stores).

I want to take this a step further. I want to have a microservice for the write model, and another one for the read model, for scalability concerns. Each service with their own database. I want to use messaging to maintain eventual consistency between the write and read model.

I'm concerned with how this approach would affect the user experience in a frontend app for this backend.

Say that a user creates a post. The write service returns ok, and (by design) the user then is instantly redirected to the page displaying the newly created post and its contents.

However, due to the async nature of messaging, the read model may not be consistent with the write transaction, and I risk a scenario where the read service does not yet contain the newly created post at the time where the frontend attempts to call it.

What is the conventional / industry standard way of handling a scenario like this?

2
  • "I'm concerned with how this approach would affect the user experience in a frontend app for this backend." - So why are you doing it this way? System design is a trade-off between user experience and technical constraints. If you're going to impose constraints on your user experience, you better have a good technical reason to do so. Eventual consistency is usually used in the situation when lack of immediate consistency is not detrimental to the user. – Ant P Nov 20 '19 at 12:54
  • The standard is you can no longer rely on direct redirects but rather have to wait until the data is published by the microservice (which optionally notifies subscribed fe clients about the fact). E.g. Look at Google groups, when you post a jew reply, it isn't until a few minutes to few hours when you can view your post, even on boards without moderation, exactly for this reason, it takes time before the data is available. If this bothers you, eventual concostency should not be your way to go. – Andy Nov 20 '19 at 12:55
-1

Basically, you wait until you can read the data back before doing the redirect. "Eventual" is an unfortunate word to describe the consistency model, because it connotes a long wait. The vast majority of the time, you can measure the time it is inconsistent in milliseconds. If your latency is longer than that, either something is seriously wrong in your cluster, or you have intentionally designed it that way to take advantage of batching or spot pricing, or because of requirements like rate limiting to an upstream service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.