update data integration

Author: Jerome Boyer

cassandra/cassandra-statefulset.yml

@@ -16,6 +16,13 @@ spec:
       labels:
         app: cassandra
     spec:
+      affinity:
+        podAntiAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - topologyKey: kubernetes.io/hostname
+            labelSelector:
+              matchLabels:
+                app: cassandra
       terminationGracePeriodSeconds: 1800
       containers:
       - name: cassandra
@@ -79,8 +86,7 @@ spec:
         name: cassandra-data
       spec:
         accessModes: ["ReadWriteOnce"]
-        storageClassName: fast
         resources:
           requests:
-            storage: 2Gi
+            storage: 1Gi
 

cassandra/cassandra-volumes.yaml

@@ -4,11 +4,11 @@ kind: PersistentVolume
 metadata:
   name: cassandra-data-1
   labels:
-    type: local
+    type: glusterfs-storage
     app: cassandra 
 spec:
   capacity:
-    storage: 2Gi
+    storage: 1Gi
   accessModes:
     - ReadWriteOnce
   hostPath:
@@ -20,11 +20,11 @@ kind: PersistentVolume
 metadata:
   name: cassandra-data-2
   labels:
-    type: local
+    type: glusterfs-storage
     app: cassandra
 spec:
   capacity:
-    storage: 2Gi
+    storage: 1Gi
   accessModes:
     - ReadWriteOnce
   hostPath:
@@ -36,11 +36,11 @@ kind: PersistentVolume
 metadata:
   name: cassandra-data-3
   labels:
-    type: local
+    type: glusterfs-storage
     app: cassandra
 spec:
   capacity:
-    storage: 2Gi
+    storage: 1Gi
   accessModes:
     - ReadWriteOnce
   hostPath:

docs/data/data-integration.md

@@ -7,3 +7,13 @@ There is no universal database solution to address the variety of data requireme
 When we need to separate the write and read model, like by adapting CQRS, we need to pay attention on where the data are create first, where they should be persisted, and which representations are derived from which sources. For each target reads, what are the expected formats, and data locations?
 
 The classical approach to keep different systems data consistent, is to use two phase commit transaction, and the orchestrator to keep the write operation in expected sequence. Alternate model is to use event sourcing to keep write order in a log.
+
+## Transaction
+
+We do not want to write another book on transaction, but this is important to keep the following in mind when addressing application design and architecture:
+
+* With ACID transaction, atomicity, isolation and durability are database characteristics. Consistency is application specifics and depends on what the code set in the transaction.
+* ACID transaction is not about concurency (like it is in multithreading) but it is the ability to abort a transaction on error and have all writes from that transaction discarded.
+* ACID consistency is aimed to keep business logic invariants on the data. Database can guaranty foreign key and constraints, but not business logic invariants.
+* ACID isolation guarantees concurrently executing transactions are isolated from each other. They are serialized, which impact performance. So modern databases are using weaker algorithm for isolation.
+* ACID durability is to keep the data forever, so for single node, it is to write to harddisc, while with distributed database, a database must wait until all writes or replications are complete before claiming a transaction is successful.