The conversation

Lessons learnedExperience excerpt · English

Every time I've relaxed consistency guarantees internally in systems I've worked on (or heard …

… Every time I've relaxed consistency guarantees internally in systems I've worked on (or heard coworkers doing the same) we've come to regret it. At a startup several years ago, we needed to build an external search index for a database. The database updated live - and we had a change feed that updated the browsers live as records changed. The engineer in charge did a "good enough" job - he wrote a scrappy script that was only mostly correct. But it sometimes left the index inconsistent with the data. We got constant reports from our users about items not showing up in the search results. He would dutifully go back and fiddle with things to try and fix the problem. Eventually one of our senior engineers went in and rewrote the whole indexing script to be strictly correct. We never heard a peep about it after that - it just worked, every time. Even putting aside the frustration of our users, writing it correctly was a big win for us in terms of maintenance. Once it was correct, we didn't need to keep pulling engineering time away to fix problems. …

Original discussionData Consistency Is Overrated71 source comments · at import
3

What was this responding to?

Parent context · original excerpt

DD

I think there are two different kinds of consistency, and it's important to not conflate them. There's consistency that's internal to a system. Do all of the foreign keys line up correctly? Have I lost any data that was provided to me? Here, we can aspire to be 100% correct. I don't think the examples in this article conflict with that. Then there's consistency that's external to a system. This can be between this system and other systems, or between this system and reality. Did the operator enter the correct data for this item? Did the external system change and fail to tell me? Here there is no way to be 100% correct using only the tools that are inside the system. You need external audits, reality checks, periodic reconciliation. Critically, all of the author's examples are about external consistency (accounting matching reality; inter-system communication), but their conclusion seems…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 3

Direct replies available in this import. Original-language excerpts.

FU

>In a financial world, a bank should never print money. Except banks routinely do "print money" (if you agree that credit and money are effectively the same). Even without delving into workings of our financial system, there are enough stories of banks making mistakes which erroneously increase their liabilities to clients. Banks simply revert such mistakes if they can or sue clients if money were withdrawn before such mistake was found. So it's much closer to fuzzy/eventual consistency.

Full original
IA

> In a financial world, a bank should never print money. It's not relevant to the point but this is absolutely what banks do in the UK and I expect in most modern economies. They create money. https://www.bankofengland.co.uk/explainers/how-is-money-crea...

Full original
ZV

> Null pointers take something that should be strictly consistent (references) and make it fuzzy. I'd disagree; this is still strict consistency, at least in managed languages like Java or C#. (Coming from someone who has fully embraced nulls instead of fighting them.) "Strict consistency" breaks in C and C++ where a pointer can either point to 1) a valid object, 2) be null, 3) point to an invalid address (i.e., dereferencing it crashes the program). Cases 1 and 2 can simply be distinguished by simple != 0 check. There is no (direct, simple, portable, defined by the language) check to distinguish between cases 1 and 3, which is where the inconsistency arises.

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.