If you have two or more services that need to agree about state, and you have some set of rules that govern what state changes are valid, and you don't want to mess around with any of this "what do we do when we miss and update vs when we get two of the same update" nonsense, and the services aren't in a position to query the same database, then you should really consider a permissioned blockchain. Consensus hard, but it's harder if you're not using tools that understand that what they're going for is consensus.

▲

Xirdus 2 hours ago | parent [-]

99% of the time (and all 3 times in the blog post), there is only one source of truth for any piece of data, and state transitions are completely arbitrary. Blockchain is almost always the wrong solution.

	▲	Terr_ an hour ago \| parent [-]
		> Blockchain is almost always the wrong solution. Especially since in most of the cases where it's not-totally-insane to use, the right solution is the classic distributed database which came first, where the ledger is among predefined/controlled node-membership... as opposed to a bloated mass of workarounds-upon-workarounds to make it survive being ungovernable. I've seen some boosters pivot to saying "private blockchain", but that's a vapid marketing-lie, a contradiction like selling "single-user Twitter" when really it's just a blog.