Welcome to the Joshua Matos show your place for diving deep into the vast field of software engineering I'm Joshua Matos your full-stack software engineer and I'm here to make sure you become the most awesome software engineer today's episode we'll be exploring event driven architecture event dispatching spring cloud dataflow and advanced message queuing protocol we'll touch on some of the cloud services you can use too so what is event driven architecture why should we care about it and most excitingly what can we achieve with it suppose you didn't know how to leverage these powerful Tools in that case you can transform your organization by enabling them to implement microservices event driven architecture and most importantly allow your teams to make real-time data-driven decisions knowing about event-driven architecture and how to leverage message broker systems will make you an invaluable asset as a software engineer event driven architecture Eda is a software design Paradigm centered on events driving communication for instance an item purchased at a counter triggers an event to update the inventory is design really emphasizes the production detection and consumption of events events are triggered communication is made decouple Services collaborate and the systems rely on eventual consistency we'll talk a little bit more about eventual consistency later Eda decouples services and enables asynchronous communication which makes your environment scalable this decoupling mechanism alleviates bottlenecks your application doesn't have to wait for a message to be received applications continue with their workload while sending information elsewhere to be processed imagine if the customer had to wait for the inventory item to be updated before being able to make the purchase applications become more resilient to failure as Services can operate independently if a service encounters an issue the rest of your system will continue to run this spot tolerant nature ensures the systems remain functional delivering consistent and uninterrupted Services event-driven applications core strength lies in its ability to build systems that respond to events real time by proactively reacting to events applications can provide instantaneous updates real-time notifications and dynamic responses enhancing user experience and driving data decision making it's worth noting that spring boot uses concepts of event dispatching to enable the publication of events to other services this powerful pattern can be implemented with or without a message broker system streaming is another technique within Eda enables the processing of events as they occur such as financial data or sensor data streams can be used for filtering data data enrichment and other Technologies like machine learning in an event-driven architecture separate microservices may be responsible for their part of the domain it could be an inventory equipment or a user domain and an Eda these systems would either publish or consume events the messages can be sent to All Systems only one or several and this type of architecture communication is asynchronous events May not always arrive simultaneously your customer may purchase an item that sends an event that updates the inventory and cart system these messages will not necessarily arrive at the same time which is otherwise known as eventual consistency Eda is powerful but not ubiquitous so you may have to move your organization or software development team toward an event driven architecture one issue you may encounter when introducing an event-driven architecture into your company is that the current code base is monolithic meaning the applications are tightly coupled the front end and back end services are tied closely often in the same repository monoliths are usually deployed as a single individual unit shifting to an event-driven architecture creates a more resilient and scalable infrastructure the first step often involves moving to microservices simply separating the back and front ends can most easily accomplish this doing something as simple as this can help shift your organization mindset on designing and coding software another approach is to create a new service independent of the application does the application require a new inventory service create a separate backend only that responds to inventories as time passes you can introduce new technologies that facilitate your microservices and enables event-driven architecture let's talk about spring boot's event dispatching and how to use it to improve your software development events are a tool that allow different parts of your application to communicate with each other and help ensure your application remains decoupled often when one part of your application needs to collaborate with another part you'll inject one class into another and then call one of its methods or an API is introduced into an application used throughout the code base essentially coupling your application tightly and spring boot you can Implement event dispatching to help overcome this Pitfall by extending the application abstract class or using another pre-built type such as the application event publisher class that lets you publish events right into spring context events can fire off to another service that can exist inside your code base or with minimal configuration externally these are many use cases for event dispatching it's vital that you know what they are the more you know about it the better you can use event dispatching to log events in your application this can help with debugging and monitoring depending on your environment you can come up with exciting use cases such as sending logs to a database for storage or a security service event dispatching can notify users on other systems when certain events occur this can be used for sending email notifications when a new user registers or SMS notifications when a product is out of stock event dispatching can coordinate the behavior of different parts of your application for example you could use event dispatching for adding a student to a university and a roster for a university class and two separate databases in your architecture you'll likely start with this approach as it's the simplest implement you'll rely on events to execute other parts of your code and only verify the event was triggered in a unit or integration test event dispatching is a powerful technique that can make your application more modular reusable and easier to test if you still need to start using event dispatching I encourage you to try it you may be surprised how much it can improve your code the caveat being is that it can also complicate your code if it isn't clear that other events are being triggered now when you start leaning towards an event driven architecture there are some questions you should ask yourself how resilient are my events can I scale my systems depending on the use case how do we make events more resilient a great way to make a more resilient event driven architecture is to offload your events to another service asynchronously this is ampq or Advanced messaging queuing protocol at the heart of asynchronous communication protocols ampq is a protocol that standardizes how messages should be transported between applications like the shipping lanes of our ocean mpq specifies how messages are formatted addressed transported and confirmed ensuring reliable and predictable point-to-point or point-to-multipoint Communications the protocol is designed around these Core Concepts exchanges cues bindings and topics exchanges are entry points for messages there are akin to Ports of countries or messages or ships first arrive from a publisher cues are buffers that store messages if exchanges are ports cues are the harbors where our ships are stored until they can be processed messages are processed in order first in first out just like the grocery check outline bindings are a type of role that exchanges use to Route messages into queues think of them as InterContinental routes that defined where each ship should go the routing key determines which column the message should go to whether it's one queue or many ampq has different types of exchanges namely four direct topic fan out and headers typically you hear about topics a form of routing where messages are routed based on a match between a message routing key and the pattern used to bind a queue to an exchange the routing key is a short string the message producer generates specifying the topic to which the message belongs it can contain wow cards for example the routing key system.status would match the pattern system.astric wildcard which would route the message to any queue bound to the exchange with the same pattern direct exchanges also allow the message to be routed on the specific routing key it's a simple unicast routing if you have a queue whose binding is the same that's where it will go fan out exchanges where the routing key is ignored the message is sent out to all cues bound to The Exchange there is a scenario where you need to send a message to multiple cues this is the one for you header exchanges rely on header values instead of routing keys of course for all these messages being routed you'll have Publishers and consumers of those messages Publishers create messages and send them to exchanges exchanges use bindings are rules to decide how to route messages to cues that end up at a consumer a monitoring service can subscribe to a topic that starts with a key and a wild card and consume relevant messages such as system.status one of the
major strengths of ampq is its reliability the protocol guarantees messages delivery through acknowledgment if a message isn't acknowledged the protocol knows the message wasn't correctly delivered and tries again this ensures that no message gets lost and to stay analogous is to say it ensures our ships aren't lost and the vast ocean void enhancing the communication and system reliability in an event-driven architecture the reliability of messages is essential ensuring an event was received as an integral part of designing an ADA now let's talk about RAB and mq a popular message broker that implements the ampq protocol rapid mq at its core is an open source message broker software that implements the advanced message queuing protocol it's designed to enable Communications between different parts of a system if you wanted to ensure your spring blue application events were robust and communicate between dispersed and separate systems you'd use a message broker like rabbitmq if you have a server located somewhere else or want to share with a system in the cloud such as an S3 bucket or a database in a kubernetes pod picture rabbitmq as an Intergalactic post office your applications or planets if we stick to our Cosmic metaphor sends messages to the message broker rabbitmq ensuring they are delivered to the correct recipients no matter where their system is located in the solar system one of the greatest strengths of rabbitmq is its support for various messaging patterns rabbitmq has work or task queues if you have a resource intensive task you don't want to wait to complete you can send it as a message to a work queue where multiple workers will execute it and it does all the functions you would expect from ampq message broker such as publish subscribing routing and using topics rabbitmq is resilient to failure it guarantees that a message will be delivered even if the receiver is not ready when it's sent or if some other parts of the system have crashed rapidmq can be integrated with spring boot enabling your applications to communicate using events resiliently spring boot provides abstractions and Integrations to work with rampa mq namely the spring and PQ project it provides templates for sending and receiving messages containers and makes it easier to implement in your project rabbitmq added stream support in version 3.11 they offer large fan outs allowing multiple applications to read the same message it also has time travel so that streams can replay data streams have timestamps where a part of the stream can be picked and the data replayed streams are persistent and in rabbitmq replicate a non-destructive append Only log these features for rapidmq are a game changer and helped it to compete with Apache Kafka normally in a rabbitmq scenario messages are deleted from the queue whenever a message is consumed however streams allow a consumer to go to any point in a log and read from there rabbitmq was designed to have any empty State however now with stream support you can have large backlogs that store data there's so much more to rabbitmq it's a great option for anyone looking to implement a message broker into their architecture now let's take a deeper look into Apache Kafka Apache Kafka is a distributed event streaming platform born out of LinkedIn to handle their growing data and activity and simple terms Kafka allows us to send messages from one application to another from one system to another in real time using a publish And subscribe model as well much like a courier service it ensures our messages or events reach their intended recipient but Kafka is not just a messaging system it's a streaming platform that can store process and analyze streams of Records in real time it can handle trillions of daily events making it a favor among Tech giants like Twitter Netflix and Uber Apache Kafka is particularly valuable and modern applications for several reasons its ability to handle real-time data makes it ideal for event-driven architecture where the goal is to detect and react to changes in the state of data as soon as they occur let's say you have a retail application every time a customer places an order this generates an event Kafka and can ingest this event and notify various parts of the application perhaps the event system needs to update its stock the Billing System needs to issue an invoice and the customer needs a confirmation email this can be handled with Kafka allowing for real-time efficient processing of course the billing and inventory and customer systems would listen for the event when each received the order event they would act whether it was updating their stock issuing an invoice or sending an email confirmation the retail application is effectively decoupled from the rest of the system we could scale and evolve each system independently of each other you can then link this information to a visualization dashboard to view real-time analytics and provide your organization with business insights events would be stored in a queue your dashboard of choice or multiple dashboards would subscribe to the queue and all this would happen in real time Kafka allows for replaying events as it maintains a log of all the events that have passed to it this can be useful for debugging recovery during system failures or different use cases such as machine learning that may need access to its data in different ways how long you can keep your data can be configured using a retention policy integrating Kafka with your application can take it to the next level a distributed streaming platform like Apache Kafka can create a robust and resilient architecture for real-time data processing streaming can perform machine learning real-time anomaly detection and data enrichment data enrichment is simply taking data from one system and then adding data to it from another source suppose you have a database that stores user profiles and another that stores customer order data this data is combined into a single data structure and returned to a consumer such as the user's current cart the shopping cart service would subscribe to the user profile and transaction topics this data could then be enriched inside the service to display a profile and Order data a combination of decoupled systems coming together you can update Legacy systems with minimal Interruption to users transform and filter data in real time and connect systems through a publish And subscribe model a good thing to know about Apache Kafka is that it uses connectors to connect to external systems Source connectors can extract data from a database send it to Apache Kafka and then a sync connector can take that data from Apache Kafka and put it into another database syncs usually act on the data you are working with in some way you can track changes to the database using change data capture CDC which comes in two flavors either you can use CDC logs or CDC query CDC logs examine the database transaction or bin logs the types of logs will vary depending on the database logs are performant and aware of deletes in the database however it can require special permissions to set up you can also use CDC query it's less performant and relies on sending a query because of this it can only know what is inside of the database earlier I mentioned spring Cloud dataflow spring cloud dataflow is a powerful Cloud native toolkit that allows for developing and managing data integration and real-time data processing and pipelines if you're building a spring boot application it's a no-brainer organizations deal with massive volumes of data and the ability to efficiently process transform and analyze data is critical now spring Cloud dataflow provides a comprehensive solution to these challenges offering a flexible and scalable platform for building and managing data Pipelines it has security by standardizing and oau-2 and openid connect or authentication and authorization it enables continuous delivery and allows for upgrades and rollbacks of your Pipelines now data flow serves as a great way to enable an event-driven architecture it's also used with spring Cloud Stream app starters and has 60 pre-built sources so developers can kick-start their Solutions that's JMS Source mongodb rabbitmq gemfire cloud dataflow is also an open source framework built on top of the popular spring Boot and spring Cloud projects it provides a platform for data-driven microservice applications you can compose and orchestrate data processing pipelines known as streams and tasks based on applications to handle batch processing it supports multiple programming models such as Cloud stream and task the platform is also polygon supporting Kafka python.net and other technology polygot simply means that the platform can support multiple languages dataflow offers a plugable message broker including support for rapidmq Apache Kafka and Amazon kinesis it also has monitoring and management features to gain insights into the pipeline's performance monitor metrics troubleshoot issues and dynamically adjust the pipeline to optimize data processing it's a great tool for orchestrating streams you can have it batched in workflows scale data pipelines and orchestrate tasks combined with other tools and Technologies you can create an event-driven architecture with a rabbitmq or Apache Kafka and a spring cloud dataflow developing and learning on event driven architecture will always level up your skills I would be remiss if I didn't mention how you as a software engineer can get these Technologies in the cloud whether it's AWS Google cloud or Azure AWS offers Amazon mq Apache activemq rabbitmq Amazon Kinesis Google cloud has uh Cloud Pub sub Cloud dataflow Azure has Azure service bus event Hub and event grid as your skill set grows as software engineer you need to provide solutions to your company and the best solution may be to host your services and kubernetes or to move them to a managed service let me know what service you decided to go with and how you're implementing your event-driven architecture this has been another episode of the Joshua Matos show thanks for sticking around and I'll see you later
2023-07-28