←back to thread

How to do distributed locking (2016)

(martin.kleppmann.com)
240 points yusufaytas | 4 comments | 20 Oct 24 10:38 UTC | HN request time: 0.001s | source
Show context
galeaspablo ◴[20 Oct 24 11:56 UTC] No.41894762[source]▶
Many engineers don’t truly care about the correctness issue, until it’s too late. Similar to security.

Or they care but don’t bother checking whether what they’re doing is correct.

For example, in my field, where microservices/actors/processes pass messages between each other over a network, I dare say >95% of implementations I see have edge cases where messages might be lost or processed out of order.

But there isn’t an alignment of incentives that fixes this problem. Ie the payment structures for executives and engineers aren’t aligned with the best outcome for customers and shareholders.

replies(5): >>41894888 #>>41895051 #>>41895407 #>>41895586 #>>41897997 #
1. noprocrasted ◴[20 Oct 24 14:28 UTC] No.41895586[source]▶
> there isn’t an alignment of incentives that fixes this problem

"Microservices" itself is often a symptom of this problem.

Everyone and their dog wants to introduce a network boundary in between function calls for no good reason just so they can subsequently have endless busywork writing HTTP (or gRPC if you're lucky) servers, clients & JSON (de?)serializers for said function calls and try to reimplement things like distributed transactions across said network boundary and dealing with the inevitable "spooky action at a distance" that this will yield.

replies(2): >>41896593 #>>41897331 #
2. sethammons ◴[20 Oct 24 16:40 UTC] No.41896593[source]▶
I've worked with microservices at scale and it was fantastic. We couldn't break backwards compatibility with our API without a lot of coordination. Outside of that, you could deploy as frequently as needed and other services could update as needed to make use of new features.

The monoliths I have worked in, very contrastingly, have had issues coordinating changes within the codebases, code crosses boundaries it should not and datastores get shared and coupled to (what should be) different domains leading to slow, inefficient code and ossified options for product changes.

3. shepherdjerred ◴[20 Oct 24 18:16 UTC] No.41897331[source]▶
If you're hand-writing clients/servers/serializers instead of generating them from schema definitions then you have more fundamental issues than using microservices.
replies(1): >>41899665 #
4. sethammons ◴[21 Oct 24 00:29 UTC] No.41899665[source]▶
We hand wrote clients at my last microservice based gig. It was marginally slower than automated clients and we did run into a few cases of teams "waisting" their time writing their own clients; that was fixed by the authoring service team also authoring clients. It wasn't a big issue