diff --git a/README.md b/README.md
index e8d0638ebe77813184dd0d664c55dcf881b57705..e0de93a393b2761b730300a4f2e19f3db722bc38 100644
--- a/README.md
+++ b/README.md
@@ -94,3 +94,21 @@ In this tutorial, we used `RwLock<>` to synchronize access to the `Vec` of notif
 In Java, static variables are stored in a shared memory space, and their contents can be modified freely through static functions. Rust, however, enforces strict ownership and borrowing rules to prevent data races and ensure memory safety at compile time. A `static` variable in Rust has a fixed memory location and must be immutable unless explicitly wrapped in synchronization primitives like `Mutex<>` or `RwLock<>`. The reason for this restriction is that, in a multi-threaded environment, direct mutation of a static variable without synchronization could lead to undefined behavior, such as data races. Rust’s approach forces developers to explicitly handle synchronization, ensuring thread safety and memory correctness. This design makes Rust safer by preventing unintended modifications and enforcing concurrency safety at the language level.
 
 #### Reflection Subscriber-2
+# Assignment Answers
+
+## 1. Exploration Beyond the Tutorial Steps
+
+Yes, I have explored parts of the code outside the tutorial steps, particularly in `src/lib.rs`. From this, I learned that `lib.rs` serves as the main entry point for defining modules, re-exporting items, and managing dependencies within the project. It acts as a central hub where various components, such as controllers, services, and models, are structured. By understanding `lib.rs`, I gained insights into how Rust organizes modular code and how different components interact within the notification system. Additionally, exploring this file helped me understand the role of the `mod` keyword in declaring modules and how functions from different files are made accessible throughout the project.
+
+## 2. Observer Pattern and Multiple Instances
+
+The Observer pattern makes it easier to add new subscribers to the notification system because it decouples the notification sender from its listeners. In this implementation, a publisher (the notification service) maintains a list of observers (subscribers) and automatically notifies them of any changes. This design allows us to dynamically register new subscribers without modifying the core notification logic, making the system highly extensible. 
+
+However, spawning multiple instances of the main application introduces challenges. While adding new subscribers is straightforward, running multiple instances of the main app might lead to issues like message duplication, race conditions, or inconsistent state synchronization. Proper handling through distributed messaging queues, shared databases, or a consensus mechanism would be necessary to maintain consistency across multiple app instances.
+
+## 3. Writing Tests and Enhancing Documentation
+
+I have tried writing my own tests and enhancing documentation in the Postman collection. Writing unit tests for critical functions helped validate the correctness of the notification system, ensuring that each component behaves as expected. It also helped identify edge cases and potential bugs early in development. 
+
+Enhancing the Postman documentation was particularly useful in simplifying API testing and collaboration. By providing clear descriptions of request parameters, expected responses, and example cases, it became easier for other team members to understand and test the API endpoints. These enhancements proved beneficial both for my tutorial work and my group project, as they improved debugging efficiency and streamlined API integration.
+