the crux of crdts is for solutions that don't want to use central always online sync backends, have a need to merge deep history not just pick a winner of a global latest state but are ok with losing some conflicting detailed information stored inside your data.
- if you can just pick a global winner for the object/document after diverging histories/ conflicts its much simpler to just pick a latest win strategy especially for simple data
- if you cannot lose conflicting detail information, crdts will not solve your problems and you most probably need to implement application specific conflict resolution. an example is someone renaming a todo from "create invoice summary 2019" to "create latest invoice summary 2023" and at the same time someone else setting the "create invoice summary 2019" as done. a crdt can consistently merge the changes but you might end up with a todo that is set to done and is called "create latest invoice summary 2023" which is a wrong result
- if you can just pick a global winner for the object/document after diverging histories/ conflicts its much simpler to just pick a latest win strategy especially for simple data
- if you cannot lose conflicting detail information, crdts will not solve your problems and you most probably need to implement application specific conflict resolution. an example is someone renaming a todo from "create invoice summary 2019" to "create latest invoice summary 2023" and at the same time someone else setting the "create invoice summary 2019" as done. a crdt can consistently merge the changes but you might end up with a todo that is set to done and is called "create latest invoice summary 2023" which is a wrong result