2

In a CQRS system, the convention that we follow is we render the detail view of an aggregate(i.e getById) using the write model and views containing multiple aggregates(like a dashboard) using read model. Hence in a Sales CRM, we modeled the lead list dashboard UI using read model and lead details page using write model.

When I perform operations on the detail view of a lead, since I render the page using write model, my changes reflect immediately on UI. Eg, when I change the country of a lead, the changes can reflect on UI immediately. But when I need to provide the same api on dashboard, the changes will not be visible immediately as the read model will be eventually consistent. Similarly when performing bulk operations like update country of 10 leads, my listing page will be eventually consistent. The delay in updation will be ~1s at worst in my case as the consumers/subscribers(read models) are poll based and poll at an interval of 1s. Is there any way I can make it more real-time? I checked other CRMs where they provide seemingly immediate consistency even when performing bulk operations. Having a delay of 1s in the listing page does not give a good customer experience.

  • You say that your detail view is always up-to-date because you use the write model as a basis for that view, but are you sure that is also true if multiple users are accessing the same detail view? If user A is editing the country of a lead, can user B follow exactly (and at real-time) what user A is typing? Or do you have a delay there as well? – Bart van Ingen Schenau Sep 3 '18 at 9:34
  • @BartvanIngenSchenau No it can always happen that multiple users are working on the same aggregate at the same time and will issue commands based on their stale detail view. By real time update of detail view I meant that the user will be able to see the response of his command/api reflect immediately on UI since the detail view is being rendered from write model. – Anisha Agrawal Sep 3 '18 at 11:21
  • But that update would only be visible after submitting your own changes, which can be a very long time after the read models were updated. My point is that for the update as seen by the user, not only the update frequency of the underlying model is relevant, but also how often the view on top of it is refreshed. – Bart van Ingen Schenau Sep 3 '18 at 12:35
  • @BartvanIngenSchenau Agreed, for that we can show the last updated/refreshed time to show staleness, based on which the user can manually refresh also. Or we can send a push to the UI that new updates are available. – Anisha Agrawal Sep 3 '18 at 13:43

Your Answer

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

Browse other questions tagged or ask your own question.