@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Finite State Machine Spring State Machine States, Transitions, Events Actions, Guards Saga Design Pattern Enterprise Integration Patterns Microservices Architecture Series Part 7 of 15 To Build Cloud Native Apps Composable Enterprise Architecture

@arafkarsh arafkarsh 2 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb Cloud-Native Architecture

@arafkarsh arafkarsh 3 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

@arafkarsh arafkarsh 4 Slides are color coded based on the topic colors. Finite State Machine Spring State Machine 1 State Machine Demo States, Transitions, Events, Actions, Guards 2 Distributed Tx Saga Design Pattern Orchestrator / Choreography 3 Enterprise Integration Patterns Spring Integration 4

@arafkarsh arafkarsh 0 Code Setup o SpringBoot 2.7.2 (MVC) / SpringBoot 3.1.0 (WebFlux) o Java 8 for Compile and Java 17 to run o H2 DB or PostgreSQL database 5

@arafkarsh arafkarsh Package Structure 6 Source: https://github.com/arafkarsh Threads / Rx Java 2: https://github.com/arafkarsh/fusion-sky-threads-rx-java Spring WebFlux Reactive Programming: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc Spring MVC & Security: https://github.com/arafkarsh/ms-springboot-272-vanilla

@arafkarsh arafkarsh Codebase 7 Source: https://github.com/arafkarsh/ms-quickstart

@arafkarsh arafkarsh 1 Finite State Machines o States o Transitions 8

@arafkarsh arafkarsh Finite State Machine – States / Transitions 9 1. States: A state represents a condition or status of the system at a point in time. For instance, in a traffic light system, the states could be 'Green,' 'Orange,’ or 'Red.’ In a software system, the state might represent whether the system is in 'start-up,' 'operation,’ or 'shutdown' mode. Each finite state machine must have at least one state and one of those states is designated as the starting state or initial state. 2. Transitions: Transitions are the paths from one state to another. Events or conditions trigger them. For example, a timer reaching zero might trigger a transition from 'Green' to 'Orange' in a traffic light system. Each transition is associated with a specific condition that must be fulfilled to move from one state to another.

@arafkarsh arafkarsh Understanding Finite State Machine 10 S1 S2 S3 T1 T2 T3 T4 States Transitions Transitions

@arafkarsh arafkarsh Deterministic / Non-Deterministic State Machines 11 DFA (Deterministic Finite Automata): • A real-world example of a DFA could be a turnstile at a train station or amusement park. The turnstile has two states: Locked and Unlocked. When you insert a ticket or token (input), the state changes from Locked to Unlocked. After you pass through (another input), it changes back to the Locked state. At any point, the turnstile has a deterministic next state for a given input. NFA (Non-deterministic Finite Automata): • A real-world example of an NFA is less common because NFAs allow a system to be in multiple states at once or make transitions without specific inputs, which only sometimes occurs in everyday physical systems. However, in computer science, we often use NFAs while designing algorithms or systems, such as pattern-matching algorithms used in text editors, compilers, and the design of certain types of computer hardware (Network Routers, FPGAs).

@arafkarsh arafkarsh Spring State Machine o States o Transitions: Triggers (Events, Timers, Choices) o Guards / Actions o Extended State o Choice o Entry / Exit States 12

@arafkarsh arafkarsh Spring State Machine 13 State Machine: The main entity that drives a collection of states, together with regions, transitions, and events. State: A state models a situation during which some invariant condition holds. The state is the main entity of a state machine where events drive state changes. Event: An entity sent to a state machine drives various state changes. Initial State: A unique state in which the state machine starts. The initial state is always bound to a particular state machine or region. A state machine with multiple regions may have multiple initial states

@arafkarsh arafkarsh Spring State Machine 14 Extended State: An extended state is a special set of variables kept in a state machine to reduce the number of needed states. Transition: A transition is a relationship between a source and target states. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the state machine’s complete response to an event of a particular type. End State: (Also called a final state.) A special kind of state signifying that the enclosing region is completed. If the enclosing region is directly contained in a state machine and all other regions in the state machine are also completed, the entire state machine is completed.

@arafkarsh arafkarsh Spring State Machine 15 Guard: A boolean expression evaluated dynamically based on the value of extended state variables and event parameters. Guard conditions affect the behavior of a state machine by enabling actions or transitions only when they evaluate to TRUE and disabling them when they evaluate to FALSE. Action: A action is a behavior run during the triggering of the transition. Choice State: A pseudo state that allows for making a transition choice based on (for example) event headers or extended state variables. Region: A region is an orthogonal part of either a composite state or a state machine. It contains states and transitions. Junction State: A pseudo state that is relatively similar to choice state but allows multiple incoming transitions, while choice allows only one incoming transition.

@arafkarsh arafkarsh Spring State Machine 16 Fork State: A pseudo state that gives controlled entry into a region. Join State: A pseudo state that gives controlled exit from a region. Entry Point: A pseudo state that allows controlled entry into a submachine. Exit Point: A pseudo state that allows controlled exit from a submachine. History State: A pseudo state that lets a state machine remember its last active state. Two types of history state exists: shallow (which remembers only top level state) and deep (which remembers active states in sub-machines).

@arafkarsh arafkarsh 2 State Machine Demo o Order Processing State Machine Configuration o Order Processing using State Machine o Order Entities and States, Events, Results 17

@arafkarsh arafkarsh Order State Machine Config 18 Order State Machine Config Order State Machine Listener Adapter Order State Change Interceptor Order State Details Order History Service Define States and Transitions Handles State Changes Handles Post State Transitions Keeps Order States in Request Scope Service to Persist Order State Transition History Setting up the State Machine Factory

@arafkarsh arafkarsh Order Processing 19 Order State Machine Manager Order State Machine Actions Order State Machine Error Handler Order State Machine Guards Restores State Machine and Send Messages to State Machine Globally Handling Error Actions for Every State Guards to Validate the States and Control the Flow Order Service Implementation Handles Messages to State Machine Manager Order Process Controller Handles all the REST Endpoints State Machine is handled in stateless Architecture. State Machine is Restored using OSM Manager.

@arafkarsh arafkarsh Order Entity 20 Order Entity Order Items Entity 1 * Shipping Address (VO) Order State History Entity 1 1 1 * Order Entities / Repository Order State Order Event Order Result Order Notes Order Constants Enumerations

@arafkarsh arafkarsh State Machine 21

@arafkarsh arafkarsh State Machine – In Progress Details 22

@arafkarsh arafkarsh State Machine Code base o States and Transitions o Actions / Guards o Restore State Machine o Error Handling 23 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Machine – States 1/2 24

@arafkarsh arafkarsh State Machine – States 2/2 25 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Machine – Transitions 1/4 26 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Machine – Transitions 2/4 27 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Machine – Transitions 3/4 28 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Machine – Transitions 4/4 29 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh Actions 30 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh Guards 31 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh Error Handling 32 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Auto Transitioning 33 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Machine Restore 34 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh Communicating with State Machine 35 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh Communicating with State Machine 36 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh State Change through Interceptor 37

@arafkarsh arafkarsh State Change through Listener 38 Source: https://github.com/arafkarsh/ms-springboot-272-java-8

@arafkarsh arafkarsh 3 Distributed Transactions 39 • Saga Design Pattern • Features • Handling Invariants • Forward recovery • Local Saga Feature • Distributed Saga • Use Case: Distributed Saga

@arafkarsh arafkarsh Distributed Transactions: 2 Phase Commit 2 PC or not 2 PC, Wherefore Art Thou XA? 40 How does 2PC impact scalability? • Transactions are committed in 2 phases. • This involves communicating with every database (XA: eXtended Architecture Resources) involved to determine if the transaction will commit (Prepare) in the 1st phase. • During the 2nd phase, each database is asked to complete the Commit. • While all of this coordination is going on, locks in all of the data sources are being held. • The longer duration locks create the risk of higher contention. • Additionally, the two phases require more database processing time than a single-phase commit. • The result is lower overall TPS in the system. Transaction Manager XA Resources Request to Prepare Commit Prepared Prepare Phase Commit Phase Done Source : Pat Helland (Amazon) : Life Beyond Distributed Transactions Distributed Computing : http://dancres.github.io/Pages/ Solution : Resilient System • Event Based • Design for failure • Asynchronous Recovery • Make all operations idempotent. • Each DB operation is a 1 PC 1 2

@arafkarsh arafkarsh Distributed Tx: SAGA Design Pattern instead of 2PC 41 Long Lived Transactions (LLTs) hold on to DB resources for relatively long periods of time, significantly delaying the termination of shorter and more common transactions. Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA T1 T2 Tn Local Transactions C1 C2 Cn-1 Compensating Transaction Divide long–lived, distributed transactions into quick local ones with compensating actions for recovery. Travel : Flight Ticket & Hotel Booking Example BASE (Basic Availability, Soft State, Eventual Consistency) Room Reserved T1 Room Payment T2 Seat Reserved T3 Ticket Payment T4 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Ticket Reservation C3

@arafkarsh arafkarsh SAGA Design Pattern Features 42 1. Backward Recovery (Rollback) T1 T2 T3 T4 C3 C2 C1 Order Processing, Banking Transactions, Ticket Booking Examples Updating individual scores in a Team Game. 2. Forward Recovery with Save Points T1 (sp) T2 (sp) T3 (sp) • To recover from Hardware Failures, SAGA needs to be persistent. • Save Points are available for both Forward and Backward Recovery. Type Source: SAGAS (1987) Hector Garcia Molina / Kenneth Salem, Dept. of Computer Science, Princeton University, NJ, USA

@arafkarsh arafkarsh Handling Invariants – Monolithic to Micro Services 43 In a typical Monolithic App Customer Credit Limit info and the order processing is part of the same App. Following is a typical pseudo code. Order Created T1 Order Microservice Credit Reserved T2 Customer Microservice In Micro Services world with Event Sourcing, it’s a distributed environment. The order is cancelled if the Credit is NOT available. If the Payment Processing is failed then the Credit Reserved is cancelled. Payment Microservice Payment Processed T3 Order Cancelled C1 Credit Cancelled due to payment failure C2 Begin Transaction If Order Value <= Available Credit Process Order Process Payments End Transaction Monolithic 2 Phase Commit https://en.wikipedia.org/wiki/Invariant_(computer_science)

@arafkarsh arafkarsh 44 Use Case : Restaurant – Forward Recovery Domain The example focus on a concept of a Restaurant which tracks the visit of an individual or group to the Restaurant. When people arrive at the Restaurant and take a table, a table is opened. They may then order drinks and food. Drinks are served immediately by the table staff, however food must be cooked by a chef. Once the chef prepared the food it can then be served. Payment Billing Dining Source: http://cqrs.nu/tutorial/cs/01-design Soda Cancelled Table Opened Juice Ordered Soda Ordered Appetizer Ordered Soup Ordered Food Ordered Juice Served Food Prepared Food Served Appetizer Served Table Closed Aggregate Root : Dinning Order Billed Order T1 Payment CC T2 Payment Cash T3 T1 (sp) T2 (sp) T3 (sp) Event Stream Aggregate Root : Food Bill Transaction doesn't rollback if one payment method is failed. It moves forward to the NEXT one. sp Network Error C1 sp

@arafkarsh arafkarsh Choreography Vs. Orchestration 45 1. Choreography: In this model, each local transaction publishes domain events that trigger local transactions in other services. There is no central coordination. The logic is distributed among the participants, which means that it must be a collaborative process. 2. Orchestration: In this model, an orchestrator (object) tells the participants what local transactions to execute. The logic for the distributed transaction is centralized in the orchestrator. Comparison of Event Choreography and Orchestration Techniques in Microservices Architecture Chaitanya K Rudrabhatla, Executive Director, Solution Architect, Media & Entertainment Domain, LA USA

@arafkarsh arafkarsh Choreography: Local SAGA Features 46 1. Part of the Microservices 2. Local Transactions and Compensation Transactions 3. SAGA State is persisted 4. All the Local transactions are based on Single Phase Commit (1 PC) 5. Developers need to ensure that appropriate compensating transactions are Raised in the event of a failure. API Examples @StartSaga(name=“HotelBooking”) public void reserveRoom(…) { } @EndSaga(name=“HotelBooking”) public void payForTickets(…) { } @AbortSaga(name=“HotelBooking”) public void cancelBooking(…) { } @CompensationTx() public void cancelReservation(…) { }

@arafkarsh arafkarsh Choreography: Use Case: Travel Booking 47 Travel : Hotel Booking / Car Booking / Flight Booking Example Room Reserved T1 Room Payment T2 Car Reserved T3 Car Payment T4 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Car Reservation C3 Seat Reserved T5 Ticket Payment T6 Cancelled Seat Reservation C4 Cancelled Ticket Payment C5 Distributed Tx Done Hotel Microservice Rental Microservice Travel Microservice

@arafkarsh arafkarsh Orchestration: SAGA Execution Container (SEC) 48 1. SEC is a separate Process 2. Stateless in nature and Saga state is stored in a messaging system (Kafka is a Good choice). 3. SEC process failure MUST not affect Saga Execution as the restart of the SEC must start from where the Saga left. 4. SEC – No Single Point of Failure (Master Slave Model). 5. Distributed SAGA Rules are defined using a DSL.

@arafkarsh arafkarsh Orchestrator: Use Case: Travel Booking – Distributed Saga (SEC) 49 Hotel Booking Car Booking Flight Booking Saga Execution Container Start Saga {Booking Request} Payment End Saga Start Saga Start Hotel End Hotel Start Car End Car Start Flight End Flight Start Payment End Payment Saga Log End Saga {Booking Confirmed} SEC knows the structure of the distributed Saga and for each of the Request Which Service needs to be called and what kind of Recovery mechanism it needs to be followed. SEC can parallelize the calls to multiple services to improve the performance. The Rollback or Roll forward will be dependent on the business case. Source: Distributed Sagas By Catitie McCaffrey, June 6, 2017

@arafkarsh arafkarsh Orchestrator: Use Case : Travel Booking – Rollback 50 Hotel Booking Car Booking Flight Booking Saga Execution Container Start Saga {Booking Request} Payment Start Comp Saga End Comp Saga Start Hotel End Hotel Start Car Abort Car Cancel Hotel Cancel Flight Saga Log End Saga {Booking Cancelled} Kafka is a good choice to implement the SEC log. SEC is completely STATELESS in nature. Master Slave model can be implemented to avoid the Single Point of Failure. Source: Distributed Sagas By Catitie McCaffrey, June 6, 2017

@arafkarsh arafkarsh Performance: Choreography Vs. Orchestration 51 175 ms : Choreography 8500 ms : Orchestration Comparison of Event Choreography and Orchestration Techniques in Microservices Architecture Chaitanya K Rudrabhatla, Executive Director, Solution Architect, Media & Entertainment Domain, LA USA

@arafkarsh arafkarsh Choreography Service: Use Case: Travel Booking 52 Travel : Hotel Booking / Car Booking / Flight Booking Example Room Reserved T2 Room Payment T3 Car Reserved T4 Car Payment T5 Cancelled Room Reservation C1 Cancelled Room Payment C2 Cancelled Car Reservation C3 Seat Reserved T6 Ticket Payment T7 Cancelled Seat Reservation C4 Cancelled Ticket Payment C5 Distributed Tx Done Hotel Microservice Rental Microservice Travel Microservice Reservation Microservice Reservation Completed T8 Reservation Incomplete T8 Reservation Request T1 S

@arafkarsh arafkarsh Scalability Requirement in Cloud 53 1. Availability and Partition Tolerance is more important than immediate Consistency. 2. Eventual Consistency is more suitable in a highly scalable Cloud Environment 3. Two Phase Commit has its limitations from Scalability perspective and it’s a Single Point of Failure. 4. Scalability examples from eBay, Amazon, Netflix, Uber, Airbnb etc.

@arafkarsh arafkarsh Libraries to Support Saga Design Pattern 54 1. Eventuate Tram and Eventuate Local (Both): Eventuate Tram and Eventuate Local are Java libraries that help handle distributed transactions using both choreography and orchestration. Eventuate Tram supports traditional JDBC/JPA- based persistence, while Eventuate Local supports event sourcing. 2. Axon Framework (Both): Axon is a Java-based framework that can handle both the orchestration and choreography of Saga design patterns. This framework is designed for building scalable and extensible microservices. 3. Spring State Machine (Orchestration): While not explicitly a Saga pattern library, the Spring State Machine can be adapted to orchestrate sagas. It's designed to manage stateful entities in Spring-based Java applications, which can be used to coordinate transactions across multiple services. 4. Camunda (Orchestration): Camunda is an open-source platform for workflow and decision automation. While not a dedicated Saga pattern library, it can handle the orchestration of sagas using BPMN workflows. It supports Java, but it also has REST APIs, so it's accessible from other languages. 5. Netflix Conductor (Orchestration): Conductor is a microservices orchestration engine developed by Netflix. It's primarily used for orchestrating complex distributed systems and can be used to manage sagas. It supports Java. 6. Zeebe (Orchestration): Zeebe is a workflow engine designed to meet the scalability requirements of high- performance applications running on cloud-native and event-driven architectures. It can handle the orchestration of sagas and supports Java, among other languages. 7. Cadence Workflow (Both): Cadence is a distributed, scalable, durable, and highly available orchestration engine developed by Uber. It supports long-running, durable workflows, and it can manage sagas. The Cadence Java client provides a framework for orchestrating sagas.

@arafkarsh arafkarsh Summary: 55 1. 2 Phase Commit Doesn’t scale well in cloud environment 2. SAGA Design Pattern Raise compensating events when the local transaction fails. 3. SAGA Supports Rollbacks & Roll Forwards Critical pattern to address distributed transactions.

@arafkarsh arafkarsh 4 Enterprise Integration Pattern 56

@arafkarsh arafkarsh 57 Enterprise Integration Patterns – Messaging System Page Number from Enterprise Integration Patterns Pattern Description Page 1 Message Channel The Message Channel is an internal implementation detail of the Endpoint interface and all interactions with the Message Channel are via the Endpoint Interfaces. 60 2 Message To support various message exchange patterns like one-way Event Messages and Request Reply messages, Camel uses an Exchange interface that has a pattern property that can be set to In- Only for an Event Message which has a single inbound Message or In-Out for a Request-Reply where there is an inbound and outbound message. 53 3 Message Endpoint Supports 4 endpoints • Web Services: REST & SOAP • Database : JDBC • File : Reads File 95 4 Message Translator We have 3 built-in Processors 1. SQL Processor (Take DTO and pass value to query) 2. SOAP Processor (Generate SOAP Message) 3. REST Processor(Take DTO convert into respected format 85

@arafkarsh arafkarsh 58 Enterprise Integration Patterns – Messaging Systems Pattern Description Page 5 Pipes and Filters Supports the Pipes and Filters from the EIP patterns in various ways. You can split your processing across multiple independent Endpoint instances which can then be chained together. 70 6 Message Router The Message Router from the EIP patterns allows you to consume from an input destination, evaluate some predicate then choose the right output destination. 78 Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 59 Enterprise Integration Patterns – Messaging Channels Pattern Description Page 7 Publish Subscribe System Supports the Publish Subscribe Channel from the EIP patterns using for example the following components: • JMS for working with JMS Topics for high performance, clustering and load balancing • XMPP when using rooms for group communication • SEDA for working with SEDA in the same Camel Context which can work in pub- sub, but allowing multiple consumers. • VM as SEDA but for intra-JVM. 106 Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 60 Enterprise Integration Patterns – Messaging Channels Pattern Description Page 8 Point to Point Channel Supports the Point to Point Channel from the EIP patterns using the following components 1. SEDA for in-VM seda based messaging 2. JMS for working with JMS Queues for high performance, clustering and load balancing 3. JPA for using a database as a simple message queue 4. XMPP for point-to-point communication over XMPP (Jabber) 5. and others 103 9 Event Driven Consumer Supports the Event Driven Consumer from the EIP patterns. The default consumer model is event based (i.e. asynchronous) as this means that the Camel container can then manage pooling, threading and concurrency for you in a declarative manner. The Event Driven Consumer is implemented by consumers implementing the Processor interface which is invoked by the Message Endpoint when a Message is available for processing. 498 Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 61 Enterprise Integration Patterns – Message Routing Pattern Description Page 10 Aggregator The Aggregator from the EIP patterns allows you to combine a number of messages together into a single message. 268 11 Content Based Router The Content Based Router from the EIP patterns allows you to route messages to the correct destination based on the contents of the message exchanges. 230 12 Message Filter The Message Filter from the EIP patterns allows you to filter messages. 237 Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 62 Enterprise Integration Patterns – Message Routing Pattern Description Page 13 Routing Slip The Routing Slip from the EIP patterns allows you to route a message consecutively through a series of processing steps where the sequence of steps is not known at design time and can vary for each message. 301 14 Load Balancer The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies. 15 Multicast The Multicast allows to route the same message to a number of endpoints and process them in a different way. The main difference between the Multicast and Splitter is that Splitter will split the message into several pieces but the Multicast will not modify the request message. Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 63 Enterprise Integration Patterns – Message Transformation Pattern Description Page 16 Content Enricher Supports the Content Enricher from the EIP patterns using a Message Translator, an arbitrary Processor in the routing logic, or using the enrich DSL element to enrich the message. 336 17 Content Filter Supports the Content Filter from the EIP patterns using one of the following mechanisms in the routing logic to transform content from the inbound message. • Message Translator • invoking a Java bean • Processor object 342 Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 64 Enterprise Integration Patterns – Others Pattern Description Page 18 Request Reply Supports the Request Reply from the EIP patterns by supporting the Exchange Pattern on a Message which can be set to In Out to indicate a request/reply. Camel Components then implement this pattern using the underlying transport or protocols. 154 19 Wire tap Wire Tap (from the EIP patterns) allows you to route messages to a separate location while they are being forwarded to the ultimate destination. 547 Page Number from Enterprise Integration Patterns

@arafkarsh arafkarsh 65 Design Patterns – Service Design Pattern Patterns Description Page 1 Request Mapper How can a service process data from requests that are structurally different yet semantically equivalent? 109 2 Response Mapper How can the logic required to construct a response be re-used by multiple services? 122 3 Data Source Adapter How can web service provide access to internal resources like database tables, domain objects, or files with a minimum amount of custom code? 137 4 Asynchronous Response Handler How can a client avoid blocking when sending a request? 184 5 Service Connector How can clients avoid duplicating the code required to use a specific service and also be insulated from the intricacies of communication logic? 168 Page Number from service Design Patterns

@arafkarsh arafkarsh 66 Design Patterns are solutions to general problems that software developers faced during software development. Design Patterns

@arafkarsh arafkarsh 67 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India: +91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

@arafkarsh arafkarsh 68 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh

@arafkarsh arafkarsh 69 Slides: https://speakerdeck.com/arafkarsh

@arafkarsh arafkarsh References 70 1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas 2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google 3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head 4. Feb 17, 2019 - Lean vs Agile vs Design Thinking 5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban 6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained. Agile Methodologies

@arafkarsh arafkarsh References 71 1. Vmware: What is Cloud Architecture? 2. Redhat: What is Cloud Architecture? 3. Cloud Computing Architecture 4. Cloud Adoption Essentials: 5. Google: Hybrid and Multi Cloud 6. IBM: Hybrid Cloud Architecture Intro 7. IBM: Hybrid Cloud Architecture: Part 1 8. IBM: Hybrid Cloud Architecture: Part 2 9. Cloud Computing Basics: IaaS, PaaS, SaaS 1. IBM: IaaS Explained 2. IBM: PaaS Explained 3. IBM: SaaS Explained 4. IBM: FaaS Explained 5. IBM: What is Hypervisor? Cloud Architecture

@arafkarsh arafkarsh References 72 Microservices 1. Microservices Definition by Martin Fowler 2. When to use Microservices By Martin Fowler 3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler 4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern 5. Thought Works: Microservices in a Nutshell 6. Microservices Prerequisites 7. What do you mean by Event Driven? 8. Understanding Event Driven Design Patterns for Microservices

@arafkarsh arafkarsh References – Microservices – Videos 73 1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 4. GOTO 2015 – Challenges Implementing Micro Services By Fred George 5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

@arafkarsh arafkarsh References 74 Domain Driven Design 1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 2. Mar 19, 2013 Domain Driven Design By Eric Evans 3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune 8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans 9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans 10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

@arafkarsh arafkarsh References 75 Event Sourcing and CQRS 1. IBM: Event Driven Architecture – Mar 21, 2021 2. Martin Fowler: Event Driven Architecture – GOTO 2017 3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016 4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS 6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

@arafkarsh arafkarsh References 76 Kafka 1. Understanding Kafka 2. Understanding RabbitMQ 3. IBM: Apache Kafka – Sept 18, 2020 4. Confluent: Apache Kafka Fundamentals – April 25, 2020 5. Confluent: How Kafka Works – Aug 25, 2020 6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020 7. Kafka Streams – Sept 4, 2021 8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018 9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

@arafkarsh arafkarsh References 77 Databases: Big Data / Cloud Databases 1. Google: How to Choose the right database? 2. AWS: Choosing the right Database 3. IBM: NoSQL Vs. SQL 4. A Guide to NoSQL Databases 5. How does NoSQL Databases Work? 6. What is Better? SQL or NoSQL? 7. What is DBaaS? 8. NoSQL Concepts 9. Key Value Databases 10. Document Databases 11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends 12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012 13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB 14. Oct 30, 2020 - Column vs Row Oriented Databases Explained 15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained! 1. Graph Databases 2. Column Databases 3. Row Vs. Column Oriented Databases 4. Database Indexing Explained 5. MongoDB Indexing 6. AWS: DynamoDB Global Indexing 7. AWS: DynamoDB Local Indexing 8. Google Cloud Spanner 9. AWS: DynamoDB Design Patterns 10. Cloud Provider Database Comparisons 11. CockroachDB: When to use a Cloud DB?

@arafkarsh arafkarsh References 78 Docker / Kubernetes / Istio 1. IBM: Virtual Machines and Containers 2. IBM: What is a Hypervisor? 3. IBM: Docker Vs. Kubernetes 4. IBM: Containerization Explained 5. IBM: Kubernetes Explained 6. IBM: Kubernetes Ingress in 5 Minutes 7. Microsoft: How Service Mesh works in Kubernetes 8. IBM: Istio Service Mesh Explained 9. IBM: Kubernetes and OpenShift 10. IBM: Kubernetes Operators 11. 10 Consideration for Kubernetes Deployments Istio – Metrics 1. Istio – Metrics 2. Monitoring Istio Mesh with Grafana 3. Visualize your Istio Service Mesh 4. Security and Monitoring with Istio 5. Observing Services using Prometheus, Grafana, Kiali 6. Istio Cookbook: Kiali Recipe 7. Kubernetes: Open Telemetry 8. Open Telemetry 9. How Prometheus works 10. IBM: Observability vs. Monitoring

@arafkarsh arafkarsh References 79 1. Feb 6, 2020 – An introduction to TDD 2. Aug 14, 2019 – Component Software Testing 3. May 30, 2020 – What is Component Testing? 4. Apr 23, 2013 – Component Test By Martin Fowler 5. Jan 12, 2011 – Contract Testing By Martin Fowler 6. Jan 16, 2018 – Integration Testing By Martin Fowler 7. Testing Strategies in Microservices Architecture 8. Practical Test Pyramid By Ham Vocke Testing – TDD / BDD

@arafkarsh arafkarsh 80 1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and most of the important components are plug‐ gable. 2. Pumba : A chaos testing and network emulation tool for Docker. 3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. 4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. 5. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. 6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. 7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or Deployment Configs and randomly terminates them. 8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. 9. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools

@arafkarsh arafkarsh References 81 CI / CD 1. What is Continuous Integration? 2. What is Continuous Delivery? 3. CI / CD Pipeline 4. What is CI / CD Pipeline? 5. CI / CD Explained 6. CI / CD Pipeline using Java Example Part 1 7. CI / CD Pipeline using Ansible Part 2 8. Declarative Pipeline vs Scripted Pipeline 9. Complete Jenkins Pipeline Tutorial 10. Common Pipeline Mistakes 11. CI / CD for a Docker Application

@arafkarsh arafkarsh References 82 DevOps 1. IBM: What is DevOps? 2. IBM: Cloud Native DevOps Explained 3. IBM: Application Transformation 4. IBM: Virtualization Explained 5. What is DevOps? Easy Way 6. DevOps?! How to become a DevOps Engineer??? 7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg 8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM 9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk 10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE 11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU 12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

@arafkarsh arafkarsh References 83 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015

@arafkarsh arafkarsh References 84 16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 21. CQS : http://en.wikipedia.org/wiki/Command–query_separation 22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 24. CAP 12 years how the rules have changed 25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 26. Pat Helland (Amazon) : Life beyond distributed transactions 27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 29. Rx Observable : https://dzone.com/articles/using-rx-java-observable