vishaltelangre · August 27, 2017 11:05 · Aug 27, 2017 · Aug 27, 2017 · Aug 27, 2017 · Aug 27, 2017
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -9,5 +9,7 @@ Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
 5. Dealing with events  
     5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP  
     5.2 At least once delivery - When you care about it, so it will retry if it doesn't get acknowledgment of delivery  
+
     5.2.1 Receiving multiple times - Need consumer logic to be idempotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
+
     5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -9,5 +9,5 @@ Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
 5. Dealing with events  
     5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP  
     5.2 At least once delivery - When you care about it, so it will retry if it doesn't get acknowledgment of delivery  
-       5.2.1 Receiving multiple times - Need consumer logic to be idempotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
-       5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
+    5.2.1 Receiving multiple times - Need consumer logic to be idempotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
+    5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -6,12 +6,8 @@ Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
 2. Local/own/isolated database for each service
 3. Cache join query information locally on respective service's DBs on each write to avoid cascaded service calls (aka joins in monolithic/shared DB)
 4. Alternative to ACID transactions is to perform multi-step operations using a state machine which can be rollbacked 
-5. Dealing with events
-
-  5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP
-
-  5.2 At least once delivery - When you care about it, so it will retry if it doesn't get ack of delivery
-
-    5.2.1 Receiving multiple times - Need consumer logic to be idemptotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
-
-    5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
+5. Dealing with events  
+    5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP  
+    5.2 At least once delivery - When you care about it, so it will retry if it doesn't get acknowledgment of delivery  
+       5.2.1 Receiving multiple times - Need consumer logic to be idempotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
+       5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -7,7 +7,11 @@ Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
 3. Cache join query information locally on respective service's DBs on each write to avoid cascaded service calls (aka joins in monolithic/shared DB)
 4. Alternative to ACID transactions is to perform multi-step operations using a state machine which can be rollbacked 
 5. Dealing with events
+
   5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP
+
   5.2 At least once delivery - When you care about it, so it will retry if it doesn't get ack of delivery
+
     5.2.1 Receiving multiple times - Need consumer logic to be idemptotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
+
     5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -9,4 +9,5 @@ Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
 5. Dealing with events
   5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP
   5.2 At least once delivery - When you care about it, so it will retry if it doesn't get ack of delivery
-    5.2.1 Receiving multiple times - Need consumer logic to be idemptotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
+    5.2.1 Receiving multiple times - Need consumer logic to be idemptotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
+    5.2.2 Receiving out of order - Need CRDT data types (https://github.com/ericmoritz/crdt) or something, which for e.g. keeps the next one in memory for a while until the prior event is received
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -5,4 +5,8 @@ Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
 1. Service for each table
 2. Local/own/isolated database for each service
 3. Cache join query information locally on respective service's DBs on each write to avoid cascaded service calls (aka joins in monolithic/shared DB)
-4. Alternative to ACID transactions is to perform multi-step operations using a state machine which can be rollbacked 
+4. Alternative to ACID transactions is to perform multi-step operations using a state machine which can be rollbacked 
+5. Dealing with events
+  5.1 At most once delivery - When you don't care about such events, like logging stuff using UDP
+  5.2 At least once delivery - When you care about it, so it will retry if it doesn't get ack of delivery
+    5.2.1 Receiving multiple times - Need consumer logic to be idemptotent (which means it should yield same result if the same operation/function is performed multiple times, i.e. f(x) == f(f(x)) == f(f(f(f(x)))))
diff --git a/Managing_Data_in_Microservices.md b/Managing_Data_in_Microservices.md
@@ -0,0 +1,8 @@
+Link to the talk: https://www.infoq.com/presentations/microservices-data-centric
+
+## Notes:
+
+1. Service for each table
+2. Local/own/isolated database for each service
+3. Cache join query information locally on respective service's DBs on each write to avoid cascaded service calls (aka joins in monolithic/shared DB)
+4. Alternative to ACID transactions is to perform multi-step operations using a state machine which can be rollbacked