diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/100-publish-subscribe.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/100-publish-subscribe.md
index f48741492..845e65b6a 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/100-publish-subscribe.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/100-publish-subscribe.md
@@ -1 +1,10 @@
-# Publish subscribe
\ No newline at end of file
+# Publish Subscribe
+
+The publish-subscribe pattern is a messaging pattern in which a publisher sends a message to a topic, and any number of subscribers can subscribe to that topic to receive the message. The publish-subscribe pattern is also known as the "observer pattern" and is a way of implementing communication between different parts of an application in a decoupled way.
+
+The main advantage of using the publish-subscribe pattern is that it allows for a clear separation of concerns between the publisher and the subscribers, and it can improve the flexibility and scalability of the system. Additionally, it allows for loose coupling between components, meaning that the publisher and subscribers are not aware of each other's existence, and can be developed, deployed, and scaled independently.
+
+Learn more from the following links:
+
+- [Publish-Subscribe Architecture (Explained by Example)](https://www.youtube.com/watch?v=O1PgqUqZKTA)
+- [Tutorial - Publish–subscribe pattern](https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/101-event-driven.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/101-event-driven.md
index e192cded1..17951b97b 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/101-event-driven.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/101-event-driven.md
@@ -1 +1,10 @@
-# Event driven
\ No newline at end of file
+# Event Driven
+
+Event-driven architecture (EDA) is a software design pattern in which the system reacts to specific events that occur, rather than being continuously polled for changes. In EDA, events are messages that are sent asynchronously between components, and the components react to the events they are interested in.
+
+The main advantage of using EDA is that it allows for a clear separation of concerns between the components, and it can improve the scalability and fault-tolerance of the system. Additionally, it allows for loose coupling between components, meaning that the components are not aware of each other's existence, and can be developed, deployed, and scaled independently.
+
+Learn more from the following links:
+
+- [Overview of Event-driven programming](https://en.wikipedia.org/wiki/Event-driven_programming)
+- [What is event-driven architecture?](https://www.redhat.com/en/topics/integration/what-is-event-driven-architecture)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/index.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/index.md
index d2c5ab579..025544a71 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/index.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/100-messaging/index.md
@@ -1 +1,14 @@
-# Messaging
\ No newline at end of file
+# Messaging
+
+Messaging is a key concept in several architectural styles, including event-driven architecture (EDA), microservices, and message-driven architecture (MDA).
+
+- Event-driven architecture (EDA)
+- Microservices
+- Message-driven architecture (MDA)
+
+In general, messaging is a powerful concept that allows for the decoupling and scalability of systems and it's used in different architectural styles to improve the flexibility and scalability of the system by allowing for loose coupling between components and making it easier to add new features or modify existing ones.
+
+Learn more from the following links:
+
+- [Architectural Styles in Software Engineering](https://shapingsoftware.com/2009/02/09/architectural-styles/)
+- [Architectural Messaging Patterns](https://www.redhat.com/architect/architectural-messaging-patterns)
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/100-client-server.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/100-client-server.md
index a2cd87f23..8ad417502 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/100-client-server.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/100-client-server.md
@@ -1 +1,9 @@
-# Client server
\ No newline at end of file
+# Client Server
+
+The client-server architecture is a common architecture pattern used in distributed systems, where a client (or multiple clients) send requests to a server, and the server responds to those requests. The client and server are separate entities that communicate over a network, such as the Internet or a local network.
+
+The client is responsible for presenting the user interface and handling user input, while the server is responsible for processing the requests and returning the appropriate response. The server can also handle tasks such as data storage, security, and business logic.
+
+Learn more from the following links:
+
+- [Intro to Client-server Architecture](https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1195/Arch_Design_Activity/ClientServer.pdf)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/101-peer-to-peer.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/101-peer-to-peer.md
index 2b03aef9a..0c903d991 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/101-peer-to-peer.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/101-peer-to-peer.md
@@ -1 +1,9 @@
-# Peer to peer
\ No newline at end of file
+# Peer to Peer
+
+Peer-to-peer (P2P) architecture is a distributed computing architecture in which each node (peer) in the network acts as both a client and a server. In P2P architecture, there is no central authority or server that manages the network, and each node communicates directly with other nodes to exchange information, share resources, and perform computations.
+
+The main advantage of using P2P architecture is that it allows for a more decentralized and fault-tolerant system. As there is no central authority, there is no single point of failure, and the network can continue to function even if some nodes fail. Additionally, P2P architecture can also improve scalability as the number of nodes in the network increases.
+
+Learn more from the following links:
+
+- [Peer to Peer Architecture](https://student.cs.uwaterloo.ca/~cs446/1171/Arch_Design_Activity/Peer2Peer.pdf)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/index.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/index.md
index 6d02b9a9b..5fd6215fa 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/index.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/101-distributed/index.md
@@ -1 +1,7 @@
-# Distributed
\ No newline at end of file
+# Distributed
+
+ Distributed systems refer to the design and organization of software components that are distributed across multiple devices or locations, connected via a network, and work together to achieve a common goal. The main challenge in designing distributed systems is dealing with the inherent complexity that arises from the distribution of components and the communication between them, and it requires techniques such as load balancing, replication, and partitioning to improve scalability, fault-tolerance, and performance. Additionally, security and coordination are also important aspects of distributed systems.
+
+Learn more from the following links:
+
+- [Overview of Distributed Architecture](https://www.tutorialspoint.com/software_architecture_design/distributed_architecture.htm)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/100-component-based.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/100-component-based.md
index 7d24ec118..163c0e2a9 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/100-component-based.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/100-component-based.md
@@ -1 +1,9 @@
-# Component based
\ No newline at end of file
+# Component Based
+
+In software architecture, component-based design (CBD) is an approach to designing software systems by composing them from a set of reusable and independent software components. These components encapsulate specific functionality and can be easily integrated into different parts of the system, allowing for a more modular and flexible design.
+
+In CBD, a software system is divided into a set of components, each of which has a well-defined interface and a specific responsibility. These components can be developed, tested, and deployed independently, making it easier to add new features, modify existing ones, and maintain the system.
+
+Learn more from the following links:
+
+- [Component Based Software architecture](https://www.tutorialspoint.com/software_architecture_design/component_based_architecture.htm)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/101-monolithic.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/101-monolithic.md
index 9c474a4d7..0073b0e13 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/101-monolithic.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/101-monolithic.md
@@ -1 +1,11 @@
-# Monolithic
\ No newline at end of file
+# Monolithic
+
+In software architecture, monolithic architecture is a design approach in which a software system is built as a single, integrated, and self-contained unit. In a monolithic architecture, all the components of the system are tightly coupled and depend on each other. This means that changes in one part of the system may affect other parts of the system.
+
+A monolithic architecture is often used for small to medium-sized systems, where the complexity of the system is manageable and the need for scalability and flexibility is not as high. In a monolithic architecture, the entire system is typically built, deployed, and executed as a single unit, which can make it easier to understand and manage the system.
+
+Learn more from the following links:
+
+- [Overview of Monolithic Architecture](https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith)
+- [What is Monolithic architecture?](https://www.techtarget.com/whatis/definition/monolithic-architecture)
+- [What is Software Architecture? (Monolithic vs. Layered vs. Microservice)s](https://www.youtube.com/watch?v=_07NtoK-Kns)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/102-layered.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/102-layered.md
index a5e4eb529..0c4de8c07 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/102-layered.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/102-layered.md
@@ -1 +1,10 @@
-# Layered
\ No newline at end of file
+# Layered
+
+In software architecture, layered architecture is a design approach in which a software system is divided into a set of layers, each of which has a specific responsibility and communicates with the other layers through well-defined interfaces. This approach allows for a more modular and flexible design, where each layer can be developed, tested, and deployed independently, making it easier to add new features, modify existing ones, and maintain the system.
+
+A layered architecture is often used for large and complex systems, where the need for scalability and flexibility is high. Each layer in a layered architecture is responsible for a specific functionality and can be thought of as a "black box" with a well-defined interface. The layers communicate with each other through these interfaces, allowing for a clear separation of concerns.
+
+Learn more from the following links:
+
+- [Layered Architectures](https://www.youtube.com/watch?v=0kpTKLTx8f4)
+- [Get started with Layered Architecture](https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1195/Arch_Design_Activity/Layered.pdf)
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/index.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/index.md
index 48c63e1ea..80395392c 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/index.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/102-structural/index.md
@@ -1 +1,14 @@
-# Structural
\ No newline at end of file
+# Structural
+
+Structural architecture in software refers to the organization and design of the components of a software system, and how they interact with each other. It deals with the physical organization of the system, and the relationships between the different components.
+
+There are several different structural architecture patterns and styles that can be used to design software systems, including:
+
+- Monolithic: where the system is built as a single, integrated, and self-contained unit.
+- Layered: where the system is divided into a set of layers, each of which has a specific responsibility and communicates with the other layers through well-defined interfaces.
+- Microservices: where the system is built as a collection of small, independent, and loosely-coupled services.
+- Event-driven: where the system reacts to specific events that occur, rather than being continuously polled for changes.
+- Client-Server: where a client sends requests to a server, and the server responds to those requests
+- Peer-to-Peer: where each node in the network acts as both a client and a server
+- Component-based: where the system is composed of reusable and independent software components
+- Domain-Driven: where the system is organized around the core business domain and business entities.
\ No newline at end of file
diff --git a/src/roadmaps/software-design-architecture/content/106-architectural-styles/index.md b/src/roadmaps/software-design-architecture/content/106-architectural-styles/index.md
index 6ab57a0a5..52dddb293 100644
--- a/src/roadmaps/software-design-architecture/content/106-architectural-styles/index.md
+++ b/src/roadmaps/software-design-architecture/content/106-architectural-styles/index.md
@@ -1 +1,18 @@
-# Architectural styles
\ No newline at end of file
+# Architectural Styles
+
+Architectural styles in software refer to the overall design and organization of a software system, and the principles and patterns that are used to guide the design. These styles provide a general framework for the design of a system, and can be used to ensure that the system is well-structured, maintainable, and scalable.
+
+Some common architectural styles in software include:
+
+- Microservices: where the system is built as a collection of small, independent, and loosely-coupled services.
+- Event-Driven: where the system reacts to specific events that occur, rather than being continuously polled for changes.
+- Layered: where the system is divided into a set of layers, each of which has a specific responsibility and communicates with the other layers through well-defined interfaces.
+- Service-Oriented: where the system is built as a collection of services that can be accessed over a network.
+- Data-Centric: where the system is focused on the storage, retrieval and manipulation of data, rather than the processing of data.
+- Component-Based: where the system is composed of reusable and independent software components.
+- Domain-Driven: where the system is organized around the core business domain and business entities.
+
+Learn more from the following links:
+
+- [What is Software Architecture & Styles?](https://study.com/academy/lesson/software-architecture-styles-patterns-components.html)
+- [Types of Architectural Styles in Software Engineering](https://www.youtube.com/watch?v=2Pp0BcXN9YY)
\ No newline at end of file