Breaking Chains Benjamin Baldivia 2018-10-31 

High level Overview Mostly theory ● Present information ● Hopefully valuable ● Spark intrigue Copyright ⓒ All Right Reserved by Buzzvil 

What chains? Information shared between components can cause “coupling” between components In order to keep things simple, we may choose to keep both components executing in within a shared environment Copyright ⓒ All Right Reserved by Buzzvil 

● Simplicity ● Locality Copyright ⓒ All Right Reserved by Buzzvil Advantages 

● Shared resources Copyright ⓒ All Right Reserved by Buzzvil Disadvantages 

● Each internal system has its own resources ● Writes? ● Pull or Push? Copyright ⓒ All Right Reserved by Buzzvil Isolation of components 

● Pull ○ A/B create a variable cost workload on C ○ A/B could exhaust resources of C causing DoS Copyright ⓒ All Right Reserved by Buzzvil Pull or Push 

● Push ○ Data Duplication? ○ Strong or Eventual? ○ When to ack write? Copyright ⓒ All Right Reserved by Buzzvil Pull or Push 

● Write resources still shared (when strongly consistent) ● Same problem we had before separation Copyright ⓒ All Right Reserved by Buzzvil Writes 

● Write resources still shared (when strongly consistent) ● Same problem we had before separation Copyright ⓒ All Right Reserved by Buzzvil Writes 

● Write is exclusively a write ● Read is exclusively a read Copyright ⓒ All Right Reserved by Buzzvil Command Query Responsibility Segregation (CQRS) 

● Disclaimer: Here be dragons Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec consectetur, turpis et tempor tempus, dolor lorem facilisis nulla, sit amet tristique diam mauris sed enim. Egestas dolor. Donec ultrices odio eget dolor ullamcorper, ac ornare ligula sodales. Morbi feugiat orci at ligula ornare molestie. Praesent ultrices nisi sed lacus luctus, vel sodales eros viverra. Donec viverra convallis mi convallis auctor. In hac habitasse platea dictumst. Duis pulvinar est id diam euismod, in tempor purus faucibus. Vivamus odio quam, auctor vitae nisl ac, fringilla aliqu tempor, in iaculis nulla blandit. Curabitur placerat fermentum orci in pretium. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur faucibus faucibus velit, quis dignissim augue. Nullam fringilla nulla eu quam feugiat, in auctor nunc faucibus. Nullam venenatis, tellus ac suscipit tincidunt, ante justo luctus lacus, ut bibendum sapien massa quis mi. Morbi sit amet viverra lorem, eget vestibulum ipsum. Integer pellentesque odio in tincidunt lobortis. Sed sollicitudin dui eget leo vulputate gravida. Curabitur auctor molestie neque quis interdum. Copyright ⓒ All Right Reserved by Buzzvil Command Query Responsibility Segregation (CQRS) 

● Possibility of different read and write models ● Can be designed in a way which reads and writes scale independently Copyright ⓒ All Right Reserved by Buzzvil Command Query Responsibility Segregation (CQRS) 

● Read model can be designed to reflect only what is required to fulfill queries ● Reads can conceptually be disconnected from writes in time ● Possible but not a requirement Copyright ⓒ All Right Reserved by Buzzvil Independent data models 

● Holding mutable state causes issues ● Many “work arounds” to manage the difficulty of mutating state ● Locks (mutex, transactions, etc.) Copyright ⓒ All Right Reserved by Buzzvil System State 

● Events can be persisted before write Ack ● Reads require aggregation of events ● Events can be propagated to reads using a push based approach ● Eventually consistent (but doesn’t have to be) Copyright ⓒ All Right Reserved by Buzzvil Events instead of state? 

● System state is based solely on events ● Sometimes not feasible (binary data?) ● Component construction and destruction is deterministic at any point in time along event log in time ● New implementations can be created without interacting with old Copyright ⓒ All Right Reserved by Buzzvil Event Sourcing 

● Events can act as an the most detailed audit log possible ● Events are not lossy (when using them as source for state) ● Mutation requires additional logic to track information change Copyright ⓒ All Right Reserved by Buzzvil Events vs mutation 

● Read all events ● Filter for relevant ● Process all events based on events and relevant info for reader ● Return aggregate state ● Time consuming? Copyright ⓒ All Right Reserved by Buzzvil Reading Events? 

● Can be eventually consistent but not required ● Event recorded by any write Acks to allow consistent writes within a domain ● State can be recreated via event aggregation ● Faster read performance than aggregating per request Copyright ⓒ All Right Reserved by Buzzvil Per component state 

● Can be eventually consistent but not required ● Event recorded by any write Acks to allow consistent writes within a domain ● State can be recreated via event aggregation ● Faster read performance than aggregating per request Copyright ⓒ All Right Reserved by Buzzvil Per component state 

● No constraints other than input validation and authorization ● Write directly to event log Copyright ⓒ All Right Reserved by Buzzvil Unconstrained write 

● Ensure constraints are fulfilled when writing ● Write to instance then create even ● Should be able to be revertable in case of event log failure ● Different approaches possible Copyright ⓒ All Right Reserved by Buzzvil Constrained write 

● Isolation with the exception of a common event log ● Reads within each internal system can be completely independent of all other internal systems ● Writes still dependent on event log ● Event log can use CQRS to allow independent scaling of read/write Copyright ⓒ All Right Reserved by Buzzvil ES + CQRS 

● Martin Fowler ○ martinfowler.com ● Greg Young ● DDD community Event Sourcing and CQRS Copyright ⓒ All Right Reserved by Buzzvil More material