Expliquez le théorème CAP et comment il s'est appliqué à un système sur lequel vous avez travaillé.

CAP dit que lorsqu'une partition réseau coupe vos noeuds, vous devez choisir entre cohérence et disponibilité. Vous ne pouvez pas renoncer à la tolérance au partitionnement, parce que les réseaux tombent que vous l'ayez prévu ou non. La vraie question est donc ce que fait votre système pendant une partition : refuser les écritures pour rester correct, ou les accepter et réconcilier plus tard. Hors partition vous pouvez avoir les deux, et c'est pour ça que la latence est l'arbitrage du quotidien.

Le cadrage que j'utilise, c'est que la tolérance au partitionnement n'est pas un choix, parce que des paquets se perdent et des commutateurs tombent quelle que soit mon architecture. CAP demande donc en réalité ce que fait le système pendant qu'il est coupé : refuser l'écriture pour que personne ne lise de la donnée périmée, ou prendre l'écriture et arranger ça après. Ce que j'aime dans l'extension PACELC, c'est qu'elle nomme la partie à laquelle on a affaire tous les jours, à savoir que même quand tout va bien vous arbitrez la latence contre la cohérence, parce qu'une écriture avec quorum entre régions coûte des allers-retours. Sur un produit où j'ai travaillé, on a découpé par fonctionnalité. Tout ce qui touchait à la facturation passait par le primaire avec une garantie de lecture après écriture, parce que facturer quelqu'un deux fois ne se répare pas avec des excuses. Le fil d'activité lisait depuis les réplicas et pouvait avoir quelques secondes de retard, et personne ne l'a jamais remarqué. Même système, deux réponses, choisies par fonctionnalité plutôt qu'en religion architecturale.