<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Myanmar Cyber Youths</title>
    <description>The latest articles on DEV Community by Myanmar Cyber Youths (@myanmarcyberyouths).</description>
    <link>https://dev.to/myanmarcyberyouths</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Forganization%2Fprofile_image%2F7384%2F27e25980-52a9-42ca-ac82-7922e8e79418.png</url>
      <title>DEV Community: Myanmar Cyber Youths</title>
      <link>https://dev.to/myanmarcyberyouths</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/myanmarcyberyouths"/>
    <language>en</language>
    <item>
      <title>Leveraging RabbitMQ and Kafka for Efficient Saga and Pub-Sub Integration</title>
      <dc:creator>Aung Myat Moe</dc:creator>
      <pubDate>Mon, 16 Oct 2023 17:30:00 +0000</pubDate>
      <link>https://dev.to/myanmarcyberyouths/leveraging-rabbitmq-and-kafka-for-efficient-saga-and-pub-sub-integration-1n0j</link>
      <guid>https://dev.to/myanmarcyberyouths/leveraging-rabbitmq-and-kafka-for-efficient-saga-and-pub-sub-integration-1n0j</guid>
      <description>&lt;p&gt;&lt;a href="https://res.cloudinary.com/practicaldev/image/fetch/s--sYz5882V--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://aungmyatmoe.me/uploads/Screenshot%25202023-10-17%2520at%25209.48.05%25E2%2580%25AFAM.png" class="article-body-image-wrapper"&gt;&lt;img src="https://res.cloudinary.com/practicaldev/image/fetch/s--sYz5882V--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_800/https://aungmyatmoe.me/uploads/Screenshot%25202023-10-17%2520at%25209.48.05%25E2%2580%25AFAM.png" alt="" width="800" height="575"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Sagas and pub-sub are two important patterns in distributed systems. Sagas allow for complex transactions to be coordinated across multiple services, while pub-sub provides a way to decouple services and communicate asynchronously. RabbitMQ and Kafka are two popular messaging systems that can be used to implement sagas and pub-sub. However, each system has its own strengths and weaknesses.&lt;/p&gt;

&lt;p&gt;RabbitMQ is a good choice for sagas because it provides support for transactional messages. This means that if one step in a saga fails, all of the previous steps can be rolled back.&lt;/p&gt;

&lt;p&gt;Kafka is a good choice for pub-sub because it is highly scalable and can handle very high volumes of data. To implement a saga using RabbitMQ and Kafka, we can use the following approach:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Use RabbitMQ to coordinate the execution of the saga steps.&lt;/li&gt;
&lt;li&gt;Use Kafka to communicate between the different services involved in the saga.&lt;/li&gt;
&lt;li&gt;Use the transactional features of RabbitMQ to ensure that the saga is either completed successfully or rolled back in its entirety.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;This approach allows us to combine the strengths of both messaging systems to create a powerful and flexible solution for sagas and pub-sub. A simple example of a saga is an order processing system. The saga might involve the following steps:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Reserve inventory for the items in the order.&lt;/li&gt;
&lt;li&gt;Charge the customer's credit card.&lt;/li&gt;
&lt;li&gt;Ship the items to the customer. If any of these steps fail, the saga should roll back all of the previous steps.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;To implement this saga using RabbitMQ and Kafka, we could do the following:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Create a RabbitMQ exchange for the saga.&lt;/li&gt;
&lt;li&gt;Create a Kafka topic for each step in the saga.&lt;/li&gt;
&lt;li&gt;Create a RabbitMQ queue for each service involved in the saga.&lt;/li&gt;
&lt;li&gt;Bind the queues to the exchange using routing keys that correspond to the saga steps.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;When a customer places an order, the order processing service would publish a message to the RabbitMQ exchange. The exchange would route the message to the queue for the first step in the saga.The service that owns the first step in the saga would then consume the message from its queue. If the step is successful, the service would publish a message to the Kafka topic for the next step in the saga.&lt;/p&gt;

&lt;p&gt;The service that owns the next step in the saga would be subscribed to the Kafka topic. When it receives a message, it would consume the message and execute the step.This process would continue until all of the steps in the saga have been completed successfully. If any of the steps fail, the service that owns the step would publish a message to a special RabbitMQ queue for saga compensation.&lt;/p&gt;

&lt;p&gt;The saga compensation queue would be consumed by a separate service that would roll back all of the previous steps in the saga. This approach allows us to implement a robust and scalable saga system using RabbitMQ and Kafka. By combining the strengths of RabbitMQ and Kafka, we can create a powerful and flexible solution for sagas and pub-sub. This approach can be used to implement complex distributed systems in a reliable and scalable way.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Sync Microservices System Design in Nustshell</title>
      <dc:creator>Aung Myat Moe</dc:creator>
      <pubDate>Mon, 25 Sep 2023 15:27:08 +0000</pubDate>
      <link>https://dev.to/myanmarcyberyouths/sync-microservices-system-design-in-nustshell-2jhf</link>
      <guid>https://dev.to/myanmarcyberyouths/sync-microservices-system-design-in-nustshell-2jhf</guid>
      <description>&lt;p&gt;When I first learned about the system we had to implement, it appeared deceptively simple and concise. However, the reality was far from straightforward. The organization's diverse branches had their databases, and this forced us to reconsider how we would approach the design and development of the system.&lt;/p&gt;

&lt;p&gt;The challenge of integrating a legacy system with a modern one became evident, especially as we aimed to incorporate multi-tenancy. While multi-tenancy is suitable for databases sharing the same schema and location, our situation required a different approach. Consider a scenario where we execute a write command on database B - in the event of a bug, we need robust logging and monitoring. To address this concern, we decided to segment our services.&lt;/p&gt;

&lt;p&gt;These services are internally composed and exposed via an API gateway, offering a clear separation of internal implementation details from other developers. This approach allows us to foster collaboration with junior team members while still maintaining control over the system's architecture.&lt;/p&gt;

&lt;p&gt;To ensure the success of our system, we've applied various design patterns and techniques:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;Circuit Breaker&lt;/strong&gt; : Given the network's inherent unreliability, we've implemented circuit breakers to gracefully handle failures and disruptions.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;API Gateway&lt;/strong&gt; : We've established an API gateway to streamline and manage external communication with our services.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Database per Service&lt;/strong&gt; : Each service has its dedicated database, ensuring data isolation and scalability.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Schema per Service&lt;/strong&gt; : We've adopted a schema-per-service approach, allowing each service to manage its data structure independently.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;API Composition&lt;/strong&gt; : Our system leverages API composition to assemble complex functionalities from multiple services.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Sync Communication&lt;/strong&gt; : Synchronous communication is utilized when needed, ensuring data consistency and reliability.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Service per Team&lt;/strong&gt; : We've organized teams around specific services to enhance ownership and accountability.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Remote Procedure Invocation (RPI)&lt;/strong&gt;: RPI enables seamless communication between services, enhancing system cohesion.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Self-Registration&lt;/strong&gt; : Services self-register to simplify dynamic service discovery and orchestration.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Routing&lt;/strong&gt; : We've implemented routing mechanisms to efficiently direct requests to the appropriate services.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Service Discovery&lt;/strong&gt; : Dynamic service discovery ensures that services can locate and communicate with each other.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Observability&lt;/strong&gt; : To monitor system health and performance, we've integrated observability tools and practices.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Handling Failures and Latency&lt;/strong&gt; : Our system has robust strategies in place to deal with failures and mitigate latency issues.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;These design patterns and techniques collectively empower our system to navigate the complex landscape of multi-tenancy, network unpredictability, and evolving requirements while maintaining flexibility, reliability, and manageability."&lt;/p&gt;

</description>
      <category>microservices</category>
      <category>laravel</category>
      <category>php</category>
      <category>node</category>
    </item>
  </channel>
</rss>
