diff --git a/README.md b/README.md
index fe46a1150efc88757d9895b6186d8aec529db663..69e2960b3c81f02973535cfca40c34d4681a3947 100644
--- a/README.md
+++ b/README.md
@@ -58,12 +58,12 @@ You can install Postman via this website: https://www.postman.com/downloads/
     -   [x] Commit: `Implement delete function in Subscriber repository.`
     -   [x] Write answers of your learning module's "Reflection Publisher-1" questions in this README.
 -   **STAGE 2: Implement services and controllers**
-    -   [ ] Commit: `Create Notification service struct skeleton.`
-    -   [ ] Commit: `Implement subscribe function in Notification service.`
-    -   [ ] Commit: `Implement subscribe function in Notification controller.`
-    -   [ ] Commit: `Implement unsubscribe function in Notification service.`
-    -   [ ] Commit: `Implement unsubscribe function in Notification controller.`
-    -   [ ] Write answers of your learning module's "Reflection Publisher-2" questions in this README.
+    -   [x] Commit: `Create Notification service struct skeleton.`
+    -   [x] Commit: `Implement subscribe function in Notification service.`
+    -   [x] Commit: `Implement subscribe function in Notification controller.`
+    -   [x] Commit: `Implement unsubscribe function in Notification service.`
+    -   [x] Commit: `Implement unsubscribe function in Notification controller.`
+    -   [x] Write answers of your learning module's "Reflection Publisher-2" questions in this README.
 -   **STAGE 3: Implement notification mechanism**
     -   [ ] Commit: `Implement update method in Subscriber model to send notification HTTP requests.`
     -   [ ] Commit: `Implement notify function in Notification service to notify each Subscriber.`
@@ -79,15 +79,32 @@ This is the place for you to write reflections:
 #### Reflection Publisher-1
 
 1. **Is an interface (or trait) needed in BambangShop, or a single Model struct is enough?**
+
    In the Observer design pattern, an interface (trait) is typically used to define a contract for the `Subscriber` to ensure that all subscribers implement the required methods, such as `update`. However, in this case, we only have one type of `Subscriber` and no plans to extend it with different behaviors, so a single Model struct might suffice. Using a trait would be more beneficial if we anticipate having multiple types of subscribers with varying implementations of the `update` method.
 
 2. **Is using Vec (list) sufficient or is DashMap (map/dictionary) necessary for unique `id` in Program and `url` in Subscriber?**
+
    Using a `Vec` would require additional step to ensure uniqueness, such as iterating through the list to check for duplicates before adding a new item, which can be inefficient as the list grows. On the other hand, `DashMap` inherently enforces uniqueness of keys and provides efficient lookups, making it a better choice for managing unique `id` and `url` values. Moreover, `DashMap` is thread-safe, which is crucial in a concurrent environment.
 
 3. **Do we still need DashMap or can we implement Singleton pattern instead for the List of Subscribers (SUBSCRIBERS)?**
+
    The Singleton pattern ensures a single instance of a resource, but it does not inherently provide thread safety. On the other had, `DashMap` is specifically designed for thread-safe concurrent access to a map-like structure. Using `DashMap` simplifies the implementation of thread-safe data structure and reduces the risk of concurrency issues. Therefore, `DashMap` is a more practical choice for this case.
 
 
 #### Reflection Publisher-2
+1. **Why do we need to separate “Service” and “Repository” from a Model in the MVC compound pattern?**
+
+   Separating "Service" and "Repository" from the Model adheres to the Single Responsibility Principle (SRP). The Model focuses on representing the data structure, while the Repository handles data storage and retrieval, and the Service encapsulates business logic. This separation improves code maintainability, testability, and scalability by ensuring each layer has a distinct responsibility. It also allows for easier modifications, without affecting other parts of the application.
+
+2. **What happens if we only use the Model?**
+
+   If we only use the Model, the interactions between `Program`, `Subscriber`, and `Notification` would become tightly coupled, leading to increased code complexity. Each Model would need to handle its own data storage, retrieval, and business logic, resulting in bunch of duplicated codes and higher risk of bugs. For example, the `Notification` model might need to directly query `Subscriber` data and manage its own notification logic, making it harder to isolate and test individual components. The lack of separation would make the codebase less flexible and harder to maintain as the application grows, which makes it unscalable.
+
+3. **How does Postman help in testing my current work?** 
+
+   Postman allows me to send HTTP requests to me endpoints and verify their responses. For the current project, Postman helps in testing the `Notification` and `Product` endpoints by simulating real-world API interactions. Additionally, Postman's automated testing scripts can validate response data, ensuring that the API behaves as expected.
+
+
+
 
 #### Reflection Publisher-3