Présentation du talk de Boremi Toch et Stéphane Lundy à La Duck Conf 2018. Ma base est-elle CA, AP ou CP ? la question n'est pas toujours pertinente. Depuis qu'il est devenu branché, voire courant d'écrire sa donnée dans une base non relationnelle, il y a un théorème qui revient souvent, le théorème CAP. Mais tout rigoureux qu'il soit, ne le laissez plus parasiter vos décisions d'architecture et venez l'attaquer sous l'angle pragmatique, celui qui vous aide à concevoir vos architectures pour répondre à des besoins et enjeux métier. Commençons par un peu d'historique pour mieux appréhender le problème sous-jacent, pour ensuite mieux réfléchir aux questions pragmatiques à se poser.

1. Life After the CAP Theorem
Borémi Toch & Stéphane Lundy

2. 2
Who’s Who ?
@LSrandomBorémi Toch

3. 3
Why are we talking about a theorem ?

4. 4
From Pets to Cattle: Distributed is Becoming The Norm

5. 5
So what’s the goal ?
☉ Understand why the CAP Theorem is
not that practical, but still useful
☉ Give you practical guidelines when
dealing with distributed persistence
☉ Match the system design with the
business stakes

6. 6
From Start...

7. 7
...To Finish

8. >01 Brewer’s Conjecture

9. 9
What is distributed system ?
A distributed systemNot a distributed system

10. 10
Your guide for the hike: Mr. Eric Brewer

11. 11
You can’t have the whole pie and eat it, Eric Brewer 2000

12. 12
Getting equipped: a tiny bit of theory

13. 13
Consistency (Linearizability)
There must exist a total order on all operations such that each
operation looks as if it were completed at a single instant.
Gilbert, Lynch, 2002
v1 v2 v3
Read ReadWrite(v2) Read=> v3Write(v3)=> v1 => v3

14. 14
Availability
Every request received by a non-failing node in the system must result
in a response.
Gilbert, Lynch, 2002
Client
Request
Response

15. 15
Partition Tolerance
When a network is partitioned, all messages sent from nodes in one component
of the partition to nodes in another component are lost.
Gilbert, Lynch, 2002
Distributed System

16. 16
Partition Tolerance
When a network is partitioned, all messages sent from nodes in one component
of the partition to nodes in another component are lost.
Gilbert, Lynch, 2002
Blue Partition Green Partition

17. 17
The Completely Asynchronous Network Assumption

18. >02 Brewer’s Refresh

19. 19
2012: Second Take, by Brewer himself
☉ Must read article (available on infoQ)
☉ 12 years of insight into what his original conjecture meant
☉ Easy read with practical examples

20. 20
2015: A Critique of the CAP Theorem, by Martin Kleppmann
☉ Excellent in-depth analysis
☉ Must read to understand the in-depth limitations of the CAP Theorem
☉ Extensive bibliography to dig deeper in the current state of the art

21. CAP Theorem Dismisses Latency
☉ CAP Theorem ignores latency, even though in practice communications rely on it
☉ Availability and partition state cannot be detected instantaneously
Blue Partition Green Partition

22. 22
No one can actually forfeit Partitions

23. Consistency and Availability Need Not Be Perfect
☉ The CAP impossibility result holds only for perfect properties
☉ C & A actually range on a spectrum, where tradeoff rules the land
Always return
v0
Return latest
consistent version
Return stale version (vN, N>0)
Eventual Consistency
Super Fragile High Availability
99.999999...
availability
Useless Holy GrailPragmatic Architecture
Consistency
Availability

24. >03 How To Use It In Practice

25. 25
Easy Peasy Practical Guide

26. 26
Guideline #1: Ask The Partition Question
☉ That’s a system designer question
> Should the system restrict operations ?
> Should the system proceed ?
☉ And a designer question is actually a business decision
What should the system do when a partition occurs ?

27. 27
Guideline #2: Ask The Recovery Question
☉ A system designer has tools to do that, for instance
> Last Writer Wins
> Linearisation
> Compensation
> Human escalation
☉ But in the end that is again a business decision
How should we resolve the partition conflict ?

28. 28
Guideline #0: Don’t Forget That’s Part Of A Risk Analysis
☉ Overdesign lurks on the dark side
☉ System Designers have tools
> KISS: Keep It Simple & Stupid
> Measure, Don’t guess (aka. empiricism, test & learn, short feedback loop…)
☉ What are the risks and impacts ? ask the business people
Is the likelihood worth the complexity ?

29. 29
A nice drawing to clear things up
Time

30. 30
A nice drawing to clear things up
Time
Partition
recovery
Partition

31. 31
Hey but it’s just like
☉ Partition is by design
☉ Merge cannot always be completely
automated
Time
Merge
Local
modifications

32. >04 Other IT Examples And Patterns

33. File Synchronization
☉ Partition is by design
☉ Last Writer Wins strategy (LWW) most
of the time
☉ Conflicts are escalated to the user with
file names suffixed with (2), (3)...
Time
Back to base
Offline work

34. Document Edition
☉ Edition in the browser, with varying
update frequency
☉ Strategies: LWW for whole document
or finer text modifications updates
Time
Merge
Local
modifications

35. Optimistic Locking
Pessimistic Locking
Relational Databases Management Systems
☉ Pessimistic Locking is about
preventing partitions
☉ Optimistic Locking is about
concurrent editing with a First
Writer Wins strategy
Time

36. Blockchain Mandatory Mention
☉ Blockchains are decentralised systems
☉ In proof of work systems, the longest
chain, ie. the most powerful alternative
wins
Time
Merge
Uncertainty

37. >05 Business Already Knows It All

38. E-commerce: Stock Management
☉ What do you want :
> To check your stock before selling ?
> To sell items as fast as possible ?
☉ What do you need ?
> It depends !

39. ☉ What do you want :
> To check the disponibility of assets ?
> To encourage the cash flow ?
☉ What do you need ?
> It depends !
ATM: Withdrawal or no Withdrawal

40. ☉ What do you want :
> To check users permission ?
> To show the up to date content ?
☉ What do you need ?
> It depends !
Social Media: Timeline Consistency

41. >06 Wrap-Up

42. 42

43. So What to Think about the CAP Theorem ?
All models are wrong, but some are useful
George E. P. Box

44. 44
Take Away
☉ Though not practical, the CAP Theorem is not useless
> It helps raise questions about the Consistency-Availability trade-off
> It has fueled many distributed system designs since 2000
☉ Think about Network Partitions when you design systems
> What are the risks ?
> What to do when a partition occurs ?
> What are the rules to recover from a partition ?
☉ You may actually be more familiar with it than you think
> Don’t bicker about being CA, AP, or CP
> You already use some distributed IT tools
☉ Never forget : answers come from the business

45. 45
Initiatives To Keep An Eye On
☉ Conflict-free Replicated Data Types aka. CRDT
> Started with a paper published by Shapiro & al. 2011
> CRDT ensure worry-free partition recovery
> Some products leverage CRDT: Riak, Redis…
☉ Spanner: closing on the CAP impossibility
> Cloud Spanner is a fully managed consistent database
with high availability
> Eric Brewer, now VP of infrastructure at Google has
analysed Spanner in the CAP Theorem perspective
> Leverages Google infrastructure: highly reliable network
& high precision clocks