39 ms·
> "handwaving eventual consistency" approach for a lot of things. Which, for some systems translates to: It will be in sync when all the entropy in the univers
by jgaa 3y ago
> "handwaving eventual consistency" approach for a lot of things.
Which, for some systems translates to: It will be in sync when all the entropy in the universe is gone.
- dathinab 3y agoit's also a bit of an red hearing argument sure some systems under correct operation will never ever be fully in sync as long as they are used but most systems also do not need to be ever fully in sync it's good enough that for a specific context they will be in sync in not to much time if that context stops changing and that is something they do provide e.g. after updating a JSON blob stored under a specific id that update will be eventually available in the not too distant future and if no future changes to that document happen then in the context of that document the system will be fully in sync. But because you have very man documents there will always be a document which isn't yet in sync and in turn the system as a whole will never be fully in sync. But in the end that doesn't really matter. Also: no computer system will live that long, and if they aren't put in sync before they stop working they will literally never be fully in sync.
- Piskvorrr 3y agoTLDR: make it a Someone Else's Problem, in other words "not synced? Our code works as designed, go bother Support, or whatever."
- dathinab 3y agono its not somones else problem it's still your system but a system as a whole never being fully in sync is a red herring argument which misses the point and focuses on an aspect which might sound like a problem but hardly ever is a problem at all