<h1 id="how-to-implement-unet-in-pytorch-for-image-segmentation-from-scratch">How to Implement UNet in PyTorch for Image Segmentation from Scratch?</h1>
<h3 id="a-step-by-step-guide-to-implementing-unet-in-pytorch-from-scratch">A Step-by-Step Guide to Implementing UNet in PyTorch from Scratch</h3>
In this tutorial, we&#39;ll explore the power and walk through the implementation of UNet, one of the most popular and effective architectures for semantic segmentation in computer vision. Whether you&#39;re new to UNet or a seasoned pro, you&#39;ll discover new insights, tips, and techniques for building accurate and efficient segmentation models using PyTorch. 
Are you ready to take your image segmentation skills to the next level? So buckle up and get ready to unleash your creativity with UNet!
<h2 id="introduction">Introduction</h2>
What is image segmentation?
Image segmentation is the process of partitioning a digital image into multiple image segments, also known as image regions or image objects (sets of pixels), each of which corresponds to a different object or part of the image. 
<img src="/blog/unet/example-image-for-road-segmentation.png" alt="Figure: [Road Image segmentation](https://arxiv.org/abs/1611.09326)" title="Road Image segmentation">
Figure: <a href="https://arxiv.org/abs/1611.09326">Road Image segmentation</a>
The goal of segmentation is to simplify and/or change the representation of an image into something that is more meaningful and easier to analyze. Image segmentation is typically used to locate objects and boundaries (lines, curves, etc.) in images. 
More precisely, image segmentation is the process of assigning a label to every pixel in an image such that pixels with the same label share certain characteristics¹.
Convolutional Neural Networks (CNNs) have been instrumental in achieving state-of-the-art results in various computer vision tasks. However, when it comes to segmentation tasks, such as image segmentation or semantic segmentation, CNNs face a significant challenge. This is because segmentation requires precise localization of objects in an image. Traditional CNNs, with their fully connected layers, are not well-suited for such tasks.
To overcome this limitation, Ronneberger et al. proposed UNet, a fully convolutional neural network, which has shown remarkable success in image segmentation tasks.
<h3 id="a-brief-overview-of-unet-model-architecture">A brief overview of UNet model architecture</h3>
UNet is a popular deep-learning architecture that has been shown to achieve state-of-the-art performance on various image segmentation tasks.
<img src="/blog/unet/unet-architecture-diagram-for-image-segmentation.png" alt="Figure: [U-net architecture](https://lmb.informatik.uni-freiburg.de/people/ronneber/u-net/) (example for 32x32 pixels in the lowest resolution). Each blue box corresponds to a multi-channel feature map. The number of channels is denoted on top of the box. The x-y-size is provided at the lower left edge of the box. White boxes represent copied feature maps. The arrows denote the different operations." title="UNet Architecture Diagram for Image Segmentation">
Figure: <a href="https://lmb.informatik.uni-freiburg.de/people/ronneber/u-net/">U-net architecture</a> (example for 32x32 pixels in the lowest resolution). Each blue box corresponds to a multi-channel feature map. The number of channels is denoted on top of the box. The x-y-size is provided at the lower left edge of the box. White boxes represent copied feature maps. The arrows denote the different operations.
The U-Net is a fully convolutional neural network architecture that comprises an encoder and a decoder, with skip connections for accurate and efficient image segmentation. It has gained popularity due to its ability to produce fast and precise segmentation results.
It consists of a contracting path(encoder) and an expansive path(decoder). 
The contracting encoder of the U-Net model includes a series of convolutional and pooling layers to downsample the input image and extract its features. This section follows the conventional architecture of a convolutional neural network, with two 3x3 unpadded convolutional layers followed by a ReLU activation function and a 2x2 max pooling operation with a stride of 2. 
Additionally, at each downsampling step, the number of feature channels is doubled.
Similarly, the expansive decoder part of the U-Net architecture consists of a series of transposed convolutional and concatenation layers. It is responsible for upsampling the feature maps and combining them with the corresponding feature maps from the encoder part to produce the final segmentation map. 
Each step in the expansive path involves first upsampling the feature map, followed by a 2x2 convolution (also known as &quot;up-convolution&quot;) that halves the number of feature channels. Next, the upsampled feature map is concatenated with the corresponding feature map from the contracting path, and two 3x3 convolutions are applied, each followed by a ReLU activation function.
The U-Net architecture has skip connections between the encoder and decoder parts, which help to preserve the high-resolution details of the input image during the upsampling process. 
These skip connections concatenate the feature maps from the encoder with those from the decoder at the corresponding spatial resolution, allowing the decoder to refine the segmentation map with the information from the encoder.
<h2 id="pytorch-implementation-of-u-net-for-image-segmentation">PyTorch Implementation of U-Net for Image Segmentation</h2>
In this tutorial, I will guide you through the step-by-step implementation of U-Net in PyTorch for image segmentation tasks. 
The implementation will cover the following steps:
<ol>
<li>Defining the double convolution block</li>
<li>Implementing the encoder with downsampling</li>
<li>Implementing the decoder with skip connections and upsampling</li>
<li>Finalizing the U-Net architecture</li>
</ol>
<h3 id="1-defining-the-double-convolution-block">1. Defining the double convolution block</h3>
The double convolution block is a basic building block of the U-Net architecture. It consists of two 3x3 convolutional layers, each followed by a rectified linear unit (ReLU) activation function. This block is used multiple times throughout the encoder and decoder to extract and process features from the input image. Here&#39;s the implementation of the double convolution block in PyTorch:
<blockquote>
In this implementation, I have also included batch normalization so as to improve the performance and training speed of neural networks.
</blockquote>
<pre><code class="language-python">import torch
import torch.nn as nn

class DoubleConvBlock(nn.Module):
 &quot;&quot;&quot; A convolutional block in the UNet architecture.

 This block consists of two convolutional layers with batch 
 normalization followed by a ReLU activation function.
 &quot;&quot;&quot;

 def __init__(
 self,
 in_channels: int,
 out_channels: int,
 kernel_size: int = 3,
 padding: int = 0, # set padding to 1 to preserve the original dimension
 ) -&gt; None:
 &quot;&quot;&quot; Initializes DoubleConvBlock with specified input and output channels,
 kernel size, and padding.
 &quot;&quot;&quot;
 super(DoubleConvBlock, self).__init__()
 self.conv = nn.Sequential(
 nn.Conv2d(in_channels, out_channels, kernel_size, padding),
 nn.BatchNorm2d(out_channels)
 nn.ReLU(inplace=True),
 nn.Conv2d(out_channels, out_channels, kernel_size, padding),
 nn.BatchNorm2d(out_channels)
 nn.ReLU(inplace=True)
 )
 
 def forward(self, x) -&gt; torch.Tensor:
 x = self.conv(x)
 return x
</code></pre>
<h3 id="2-implementing-the-encoder">2. Implementing the encoder:</h3>
The encoder is part of the U-Net architecture that downsamples the input image and extracts its features. It consists of a series of double convolution blocks followed by max pooling layers. The number of feature channels is doubled at each downsampling step. Here&#39;s the implementation of the encoder in PyTorch:
<pre><code class="language-python">class Encoder(nn.Module):
 &quot;&quot;&quot;The encoder part of the UNet architecture.

 This consists of a series of convolutional blocks followed by 
 maxpooling operations..

 Args:
 channels (List[int]): A list of channels for convolutionals block.
 &gt;&gt;&gt;channels = [3, 64, 128, 256, 512, 1024]

 &quot;&quot;&quot;

 def __init__(self, channels: List[int]) -&gt; None:
 super(Encoder, self).__init__()
 self.encoder_blocks = nn.ModuleList()

 # Add a convolutional block followed by maxpooling(except last one) for each level
 for i in range(len(channels)-1):
 self.encoder_blocks.append(
 DoubleConvBlock(channels[i], channels[i+1])),

 # Add a max pooling layer after each convolutional block except the last one
 if i &lt; len(channels)-2:
 self.encoder_blocks.append(nn.MaxPool2d(kernel_size=2))

 def forward(self, x: torch.Tensor) -&gt; List[torch.Tensor]:
 encoder_features = []
 for encoder_block in self.encoder_blocks:
 x = encoder_block(x)

 # Save the output of each convolutional block
 if isinstance(encoder_block, DoubleConvBlock):
 encoder_features.append(x)

 return encoder_features
</code></pre>
<h3 id="3-implementing-the-decoder-with-skip-connections">3. Implementing the decoder with skip connections:</h3>
The decoder is the part of the U-Net architecture that upsamples the feature maps and combines them with the corresponding feature maps from the encoder to produce the final segmentation map. It consists of a series of transposed convolutional layers followed by concatenation with the corresponding feature maps from the encoder, and double convolution blocks to process the combined feature maps. Here&#39;s the implementation of the decoder with skip connections in PyTorch:
<pre><code class="language-python">class Decoder(nn.Module):
 &quot;&quot;&quot;The decoder part of the UNet architecture.

 This consists of a series of convolutional blocks with decreasing number of channels.

 Args:
 channels (List[int]): A list of channels for convolutionals block.
 &gt;&gt;&gt;channels = [1024, 512, 256, 128, 64]
 
 &quot;&quot;&quot;

 def __init__(self, channels: List[int]) -&gt; None:
 super(Decoder, self).__init__()
 self.decoder_blocks = nn.ModuleList()

 # Add a upconvolutional followed by a double convolutional block for each level
 for i in range(len(channels)-1):
 self.decoder_blocks.append(nn.ConvTranspose2d(
 channels[i], channels[i+1], 2, 2))
 self.decoder_blocks.append(
 DoubleConvBlock(channels[i], channels[i+1]))

 def _center_crop(self, feature: torch.Tensor, target_size: torch.Tensor) -&gt; torch.Tensor:
 &quot;&quot;&quot;Crops the input tensor to the target size.
 &quot;&quot;&quot;
 _, _, H, W = target_size.shape
 _, _, h, w = feature.shape

 # Calculate the starting indices for the crop
 h_start = (h - H) // 2
 w_start = (w - W) // 2

 # Crop and returns the tensor
 return feature[:, :, h_start:h_start+H, w_start:w_start+W]

 def forward(self, x: torch.Tensor, encoder_features: List[torch.Tensor]) -&gt; torch.Tensor:

 for i, decoder_block in enumerate(self.decoder_blocks):

 # Concatenate the output of the encoder with the output of the decoder
 if isinstance(decoder_block, DoubleConvBlock):
 encoder_feature = self._center_crop(encoder_features[i//2], x)
 x = torch.cat([x, encoder_feature], dim=1)

 # Apply the upconv or double convolutional block
 x = decoder_block(x)
 return x
</code></pre>
<h3 id="4-final-u-net-architecture">4. Final U-Net architecture:</h3>
The final U-Net architecture consists of an encoder and decoder with skip connections. The encoder downsamples the input image and extracts its features, while the decoder upsamples the feature maps and combines them with the corresponding feature maps from the encoder to produce the final segmentation map. Here&#39;s the implementation of the final U-Net architecture in PyTorch:
<pre><code class="language-python">class UNet(nn.Module):
 &quot;&quot;&quot;The UNet architecture. 

 Args:
 out_channels (int): The number of output channels.
 channels (List[int]): A list of channels for convolutionals block.

 Example:
 &gt;&gt;&gt; model = UNet(channels=[3, 64, 128, 256, 512], out_channels=1)
 &quot;&quot;&quot;

 def __init__(
 self,
 channels: List[int],
 out_channels: int,
 ) -&gt; None:
 super(UNet, self).__init__()
 self.encoder = Encoder(channels)
 self.decoder = Decoder(channels[::-1][:-1])
 self.output = nn.Conv2d(channels[1], out_channels, kernel_size=1)

 def forward(self, x: torch.Tensor) -&gt; torch.Tensor:
 &quot;&quot;&quot;Forward pass of the UNet architecture.
 &quot;&quot;&quot;
 encoder_features = self.encoder(x)[::-1]
 x = self.decoder(encoder_features[0], encoder_features[1:])
 x = self.output(x)
 return x

# test the model
model = UNet(channels=[3, 64, 128, 256, 512, 1024], out_channels=1)

# input tensor
x = torch.randn(1, 3, 572, 572)
y = model(x)
print(y.shape) #-&gt; torch.Size([1, 1, 388, 388])
</code></pre>
<h2 id="conclusion">Conclusion</h2>
In conclusion, UNet is an incredibly useful and efficient architecture for semantic segmentation in computer vision. In this tutorial, we have covered a step-by-step guide on how to implement UNet in PyTorch from scratch. The guide covered the fundamental concepts of image segmentation, the architecture of UNet, and the PyTorch implementation of UNet for image segmentation tasks. 
I hope that this tutorial has helped you understand the basics of UNet and how to implement it in PyTorch for your own image segmentation projects. In the upcoming tutorial, I will cover the training part of UNet in PyTorch to complete the implementation process. Stay tuned.
<h2 id="references">References:</h2>
[1] Image segmentation. Wikipedia. <a href="https://en.wikipedia.org/wiki/Image_segmentation">https://en.wikipedia.org/wiki/Image_segmentation</a>
[2] Ronneberger, O., Fischer, P., &amp; Brox, T. (2015). U-Net: Convolutional Networks for Biomedical Image Segmentation. <a href="https://arxiv.org/abs/1505.04597">ArXiv/abs/1505.04597</a>
[3] PyTorchUNet. GitHub. <a href="https://github.com/bhimrazy/unet">PyTorchUNet : A PyTorch Implementation of UNet Architecture for Semantic Segmentation of Images from scratch.</a>

Learn how to implement the UNet architecture for image segmentation from scratch using PyTorch. This tutorial covers the step-by-step process of building the model, including its architecture and necessary functions, to perform image segmentation tasks in PyTorch.

How to Implement UNet in PyTorch for Image Segmentation from Scratch?

<h1 id="what-is-event-driven-architecture-everything-you-need-to-know">What is Event-Driven Architecture? Everything You Need TO Know</h1>
Event-Driven Architecture (EDA) is a software architecture based on a pub/sub model where an event is produced by the producer, stored on the queue and consumed by the consumers as an event stream.
It has three main components i.e producer, event bus/broker and consumer. The three main components are clearly shown in the figure below.
<img src="/blog/eda/event-driven-architecture.png" alt="Event-Driven Architecture" title="Event-Driven Architecture">
Figure: Event-Driven Architecture
<h2 id="introduction">Introduction</h2>
In this guide, you will learn about event-driven architecture, its working principle, benefits, examples, etc. This guide will help you gain an idea about the producer-consumer mechanism and the flow of events.
<h3 id="what-does-an-event-mean">What does an event mean?</h3>
An event is a change in state that merits attention from systems. It may be anything like a significant change in state or an update, which is triggered when a user takes an action. For example:- An item being placed in a shopping cart on an e-commerce website.
<h3 id="event-driven-architecture-and-its-working-mechanism">Event-Driven Architecture and its working mechanism</h3>
Event-driven architecture (EDA) is a software design pattern for application development. It allows organizations to track and detect “events” (valuable business moments such as customer transactions) and then instantly act on these events.
EDA is different from a traditional request-driven system, where services needed to wait for a reply before processing the next task. An event-driven architecture is one that has the ability to detect events and react intelligently to them.
Event-driven architecture is an integration model built around the publication, capture, processing, and storage (or persistence) of events. Specifically, when an application or service performs an action or undergoes a change that another application or service might want to know about, it publishes an event—a record of that action or change—that another application or service can consume and process to perform one or more actions in turn.
The event-driven architecture enables a loose coupling between connected applications and services—they can communicate with each other by publishing and consuming events without knowing anything about each other except the event format.
This model offers significant advantages over a request/response architecture (or integration model), in which one application or service must request specific information from another specific application or service that is expecting the specific request.
Event-driven architecture maximizes the potential of cloud-native applications and enables powerful applications technologies, such as real-time analytics and decision support.
In an event-driven architecture, applications act as event producers or event consumers (and often as both).
An event producer transmits an event—in the form of a message—to a broker or some other form of event router, where the event’s chronological order is maintained relative to other events. An event consumer ingests the message—in real-time (as it occurs) or at any other time it wants—and processes the message to trigger another action, workflow, or event of its own.
In a simple example, a banking service might transmit a ‘deposit’ event, which another service at the bank would consume and respond to by writing a deposit to the customer’s statement. But event-driven integrations can also trigger real-time responses based on a complex analysis of huge volumes of data, such as when the ‘event’ of a customer clicking a product on an e-commerce site generates instant product recommendations based on other customers’ purchases.
<h2 id="event-driven-architecture-messaging-models">Event-driven architecture messaging models</h2>
There are two basic models for transmitting events in an event-driven architecture.
<h3 id="event-messaging-or-publishsubscribe">Event messaging or publish/subscribe</h3>
In the event messaging or publish/subscribe model, event consumers subscribe to a class or classes of messages published by event producers. When an event producer publishes an event, the message is sent directly to all subscribers who want to consume it.
Typically, a broker handles the transmission of event messages between publishers and subscribers. The broker receives each event message, translates it if necessary, maintains its order relative to other messages, makes them available to subscribers for consumption, and then deletes them once they are consumed (so that they cannot be consumed again).
<h3 id="event-streaming">Event Streaming</h3>
In the event streaming model, event producers publish streams of events to a broker. Event consumers subscribe to the streams, but instead of receiving and consuming every event as it is published, they can step into each stream at any point and consume only the events they want. The key difference here is that the events are retained by the broker even after the consumers have received them.
A data streaming platform, such as Apache Kafka, manages the logging and transmission of tremendous volumes of events at very high throughput (literally trillions of event records per day, in real-time, without performance lag). A streaming platform offers certain characteristics a message broker does not:
<ul>
<li>Event persistence: Because consumers may consume events at any time after they are published, event streaming records are persistent—they are maintained for a configurable amount of time, anywhere from fractions of a second to forever. This enables event stream applications to process historical data, as well as real-time data.</li>
<li>Complex event processing: Like event messaging, event streaming can be used for simple event processing, in which each published event triggers transmission and processing by one or more specific consumers. But, it can also be used for complex event processing, in which event consumers process entire series of events and perform actions based on the result.</li>
</ul>
<h2 id="benefits-of-event-driven-architecture">Benefits of event-driven architecture</h2>
Compared to the request/response application architecture, event-driven architecture offers several advantages and opportunities for developers and organizations:
<ul>
<li>Powerful real-time response and analytics: Event streaming enables applications that respond to changing business situations and make predictions and decisions based on all available current and historical data in real time. This has benefits in any number of areas—from processing streams of data generated by various IoT devices to predicting and squashing security threats on the fly, to automating supply chains for optimal efficiency.</li>
<li>Fault tolerance, scalability, simplified maintenance, versatility, and other benefits of loose coupling: Applications and components in an event-driven article aren’t dependent on each other’s availability; they can be independently updated, tested, and deployed without interruption of service, and when one component goes down a backup can be brought online. Event persistence enables the ‘replaying’ of past events, which can help recover data or functionality if there is an event consumer outage. Components can be scaled easily and independently of each other across the network, and developers can revise or enrich applications and systems by adding and removing event producers and consumers.</li>
<li>Asynchronous messaging: Event-driven architecture enables components to communicate asynchronously—producers publish event messages, on their own schedule, without waiting for consumers to receive them (or even knowing if consumers received them). In addition to simplifying integration, this improves the application experience for users. A user completing a task in one component can move on to the next task without waiting, regardless of any downstream integrations between that component and others in the system.</li>
</ul>
<h2 id="what-is-request-driven-vs-event-driven">What is Request Driven vs Event Driven?</h2>
<h3 id="request-driven-vs-event-driven">Request-driven vs Event-driven</h3>
The software world has gone microservices in the last decade. The idea is to break your business logic into small components – each component is a self-contained service – that can be maintained independently. The owner of each component can update and test that component quickly without having to consult the rest of the system.
<img src="/blog/eda/request-driven-vs-event-driven.jpg" alt="Request Driven vs Event Driven" title="Request Driven vs Event Driven">
Figure: Request Driven vs Event Driven
Microservices often go hand-in-hand with REST, a set of methods that let these microservices communicate. REST APIs are request-driven. A client (service) sends requests to tell its server exactly what to do via methods such as POST and GET, and its server responds with the results. A server has to listen to the request for the request to register.
<img src="/blog/eda/request-driven-way-vs-event-driven-way.jpg" alt="Request Driven Way vs Event Driven Way" title="Request Driven Way vs Event Driven Way">
Figure: Comparison between the request-response and event-driven approaches demonstrating how event-driven approaches provide less coupling.
Because in a request-driven world, data is handled via requests to different services, no one has an overview of how data flows through the entire system. Consider a simple system with 3 services:
<ul>
<li>A manages drivers availability</li>
<li>B manages ride demand</li>
<li>C predicts the best possible price to show customers each time they request a ride</li>
</ul>
Because prices depend on availability and demands, service C’s output depends on the outputs from services A and B. First, this system requires inter-service communication: C needs to ping A and B for predictions, A needs to ping B to know whether to mobilize more drivers and ping C to know what price incentive to give them. Second, there’d be no easy way to monitor how changes in A or B logics affect the performance of service C or to map the data flow to debug if service C’s performance suddenly goes down.
With only 3 services, things are already getting complicated. Imagine having hundreds, if not thousands of services like what major Internet companies have. Inter-service communication would blow up. Sending data as JSON blobs over HTTP – the way REST requests are commonly done – is also slow. Inter-service data transfer can become a bottleneck, slowing down the entire system.
Instead of having 20 services ping service A for data, what if whenever an event happens within service A, this event is broadcasted to a stream, and whichever service wants data from A can subscribe to that stream and pick out what it needs? What if there’s a stream all services can broadcast their events and subscribe to? This model is called pub/sub: publish &amp; subscribe. This is what solutions like Kafka allow you to do. Since all data flows through a stream, you can set up a dashboard to monitor your data and its transformation across your system. Because it’s based on events broadcasted by services, this architecture is event-driven.
Request-driven architecture works well for systems that rely more on logic than on data. Event-driven architecture works better for systems that are data-heavy.
<h2 id="event-driven-architecture-and-microservices">Event-driven architecture and microservices</h2>
In microservices—a foundational cloud-native application architecture—applications are assembled from loosely coupled, independently deployable services. The main benefits of microservices are essentially the benefits of loose coupling—ease of maintenance, the flexibility of deployment, independent scalability, and fault tolerance.
Not surprisingly, event-driven architecture is widely considered the best practice for microservices implementations. Microservices can communicate with each other using REST APIs. But REST, a request/response integration model, undermines many of the benefits of the loosely coupled microservices architecture by forcing a synchronous, tightly coupled integration between the microservices.
<h2 id="some-of-the-most-common-event-driven-architecture-tools">Some of the Most Common Event-Driven Architecture Tools</h2>
<ol>
<li>Apache Kafka: <a href="https://kafka.apache.org/">Apache Kafka</a> is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications. It is an open-source system developed by the Apache Software Foundation and written in Java and Scala.</li>
<li>Amazon Kinesis: <a href="https://aws.amazon.com/kinesis/">Amazon Kinesis</a> is a real-time data processing platform provided by Amazon Web Services. Amazon Kinesis makes it easy to collect, process, and analyze real-time, streaming data so you can get timely insights and react quickly to new information. Amazon Kinesis offers key capabilities to cost-effectively process streaming data at any scale, along with the flexibility to choose the tools that best suit the requirements of your application.</li>
<li>RabbitMQ: <a href="https://www.rabbitmq.com/">RabbitMQ</a> is an open-source message-broker software that originally implemented the Advanced Message Queuing Protocol and has since been extended with a plug-in architecture to support Streaming Text Oriented Messaging Protocol, MQ Telemetry Transport, and other protocols.</li>
<li>Apache Pulsar: <a href="https://pulsar.apache.org/">Apache Pulsar</a> is a cloud-native, multi-tenant, high-performance solution for server-to-server messaging and queuing built on the publisher-subscribe (pub-sub) pattern. Pulsar combines the best features of a traditional messaging system like RabbitMQ with those of a pub-sub system like Apache Kafka – scaling up or down dynamically without downtime. It&#39;s used by thousands of companies for high-performance data pipelines, microservices, instant messaging, data integrations, and more.</li>
</ol>
<h2 id="references">References</h2>
<ul>
<li>[1]: Event-driven architecture. In Wikipedia. <a href="https://en.wikipedia.org/wiki/Event-driven_architecture">https://en.wikipedia.org/wiki/Event-driven_architecture</a></li>
<li>[2]: Event-Driven Architecture. (n.d.). Amazon Web Services, Inc. <a href="https://aws.amazon.com/event-driven-architecture">https://aws.amazon.com/event-driven-architecture</a></li>
<li>[3]: Education, I. C. Event-Driven Architecture. IBM. <a href="https://www.ibm.com/cloud/learn/event-driven-architecture">https://www.ibm.com/cloud/learn/event-driven-architecture</a></li>
</ul>

Event-Driven Architecture (EDA) is a software architecture based on a pub/sub model where an event is produced by the producer, stored on the queue and consumed by the consumers as an event stream.

What is Event-Driven Architecture? Everything You Need To Know

Hi👋, I am Bhimraj Yadav. I like to explore Machine Learning, Data Science and Computer Vision and apply these skills to develop some cool projects.

Blog

How to Implement UNet in PyTorch for Image Segmentation from Scratch?

What is Event-Driven Architecture? Everything You Need To Know