re: Immediate vs eventual consistency VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Awesome as always. Initially, we have done immediate consistency across the board. It is easiest to reason about and create initially. And I would...
 

Thanks Kasey.

I've experienced the exact same issues you mention above, and once we made the switch to eventual we realised how easy it made things.

The funny thing is, you can architect your system as eventually consistent, then just force it to run as immediately consistent. Once you run into problems, switch over to eventual. It allows you to defer the problem, and it makes it easy to change when you need to. Building it as a immediate, then switching to eventual is a much more costly change, mainly because the immediate implementation is probably not event driven.

We used immediate for domain projections (mostly for set validations and memberships, as you phrased it) because we need them to guarantee domain constraints. There are other solutions though (think I discussed some in a previous article) but I'd love to see someone (maybe yourself :)) explore it further.

code of conduct - report abuse