Functional Design and Architecture - CAP

Hi Alex,

Eric Brewer's CAP Theorem states that for the three properties that you want in a distributed system - consistency, availability, and partition tolerance - it is only ever possible to simultaneously achieve two of them. (we typically relax one constraint, for example consistency, in real-world distributed systems). Within the context of functional programming (FP), we use immutability to reason about how a program behaves, and that helps us with things like concurrency so that we can tell that this is the value. Now, when we take that outside of a single process or some memory, and now apply that to how distributed systems (DS) behave, now we're talking about persistent storage, we're talking about messages on the wire etc. Would you then agree that FP is closer to this real-world scenarios and therefore more native for DS?

Many thanks & have a good one

Stepankha Yuliannia wrote:Hi Alex,

Would you then agree that FP is closer to this real-world scenarios and therefore more native for DS?

Many thanks & have a good one

Hi Stepankha,

I don't have enough experience and knowledge to comment on CAP and distributes systems. This is a very specific topic that I'm not familiar with.

FP is definitely closer to data processing. Essentially, FP is about data processing, and in theory, making data transformation pipelines (even distributed ones) should be simpler in FP languages.

However, there is something unfair that Python has taken this field while not being so convenient to writing such applications.

Hello Stephanka, I'm gonna be synthetic because I can't go to deep into the details.

I'd say that "traditional" Consistency in the DistSys is mostly done using something which looks like a State Machine.
Indeed there the idea of replacing a shared state is all but functional, and convergence of the results is based on protocols that hides the concurrent nature of communication, similar to what lock-free algorithms does.

Latest trends in research, regarding the CALM theorem and the use of "converging data-structures" like CRDT, are pushing something more akin to the FP approach in a way similar to what persistent data-structures do for single-machine programs.
Here the trick is to encode the state in a way that is independent of the order of operations, so that each version of the change history will converge.
So, from the technical point of view, the two approaches fork their path, in that the power of immutable DS is free sharing with no risks, which doesn't really translates to the DistSys world, where shared data is always an immutable snapshot of some message content.

To sum it up, FP immutability for shared state is already what DistSys are doing anyway, as you suggest. Yet the technical approach to consistency is something different and not necessarily related to FP design at the program level, even tho latest trends are adopting the FP mindset to solve long-standing issues.