I wonder if they could just use a simple locking scheme to prevent more than 1 parser from parsing the same feed at the same time. This sounds simpler than conflict resolution, to me.
You may want to check out Aphyr's "Call Me Maybe" series of posts about distributed databases: http://aphyr.com/tags/jepsen
The short version is that convergent conflict resolution seems intimidating but works better than locking and synchronization.
Ok, I did. I actually read the whole series, including the postgres 2-phase commit I/O error case.
I don't see where it draws that conclusion at all.
The postgres post shows that even ACID databases have network error cases which can leave your client in an indeterminate state. Fair enough. However the solution for this is... to restart your client once the network's back up. All it needs to do is requery the DB to determine the truth.
Compare that to writing conflict resolution logic for all your data because there is no single source of truth. This is considerably more complicated.
The series actually ends up recommending "the right design for the right problem space." I am not making a general SQL vs. NoSQL argument here, but I think in this case they may have taken a more complicated approach than necessary.
You may want to check out Aphyr's "Call Me Maybe" series of posts about distributed databases: http://aphyr.com/tags/jepsen
The short version is that convergent conflict resolution seems intimidating but works better than locking and synchronization.