diff --git a/README.md b/README.md
index 3043f06d471f2933c5a98c71ad06b7d900d6812c..ed7a5968e7f876047c15c4367b6e160685592bfa 100644
--- a/README.md
+++ b/README.md
@@ -48,15 +48,15 @@ You can install Postman via this website: https://www.postman.com/downloads/
     (You might want to use `cargo check` if you only need to verify your work without running the app.)
 
 ## Mandatory Checklists (Publisher)
--   [ ] Clone https://gitlab.com/ichlaffterlalu/bambangshop to a new repository.
+-   [x] Clone https://gitlab.com/ichlaffterlalu/bambangshop to a new repository.
 -   **STAGE 1: Implement models and repositories**
-    -   [ ] Commit: `Create Subscriber model struct.`
-    -   [ ] Commit: `Create Notification model struct.`
-    -   [ ] Commit: `Create Subscriber database and Subscriber repository struct skeleton.`
-    -   [ ] Commit: `Implement add function in Subscriber repository.`
-    -   [ ] Commit: `Implement list_all function in Subscriber repository.`
-    -   [ ] Commit: `Implement delete function in Subscriber repository.`
-    -   [ ] Write answers of your learning module's "Reflection Publisher-1" questions in this README.
+    -   [x] Commit: `Create Subscriber model struct.`
+    -   [x] Commit: `Create Notification model struct.`
+    -   [x] Commit: `Create Subscriber database and Subscriber repository struct skeleton.`
+    -   [x] Commit: `Implement add function in Subscriber repository.`
+    -   [x] Commit: `Implement list_all function in Subscriber repository.`
+    -   [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.`
@@ -78,6 +78,21 @@ This is the place for you to write reflections:
 
 #### Reflection Publisher-1
 
+> 1. In the Observer pattern diagram explained by the Head First Design Pattern book, Subscriber is defined as an interface. Explain based on your understanding of Observer design patterns, do we still need an interface (or trait in Rust) in this BambangShop case, or a single Model struct is enough?
+
+Using an interface (or trait in Rust) for the Subscriber in the Observer pattern creates a more extensible and scalable codebase that follows SOLID principles. Specifically, it supports the Open/Closed principle by allowing new subscribers without modifying existing code, and follows Dependency Inversion by having Publishers depend on abstractions rather than concrete implementations.
+While our current example is simple without planned extensions, meaning a single Model struct would technically work, implementing a proper interface/trait is still recommended as best practice to ensure future flexibility and maintainability.
+
+> 2. id in Program and url in Subscriber is intended to be unique. Explain based on your understanding, is using Vec (list) sufficient or using DashMap (map/dictionary) like we currently use is necessary for this case?
+
+For elements with unique identifiers like subscriber URLs or program IDs, DashMap provides significant efficiency advantages over Vec. DashMap offers O(1) constant-time lookups compared to Vec's O(n) linear search time complexity.
+This performance difference becomes increasingly important as the collection grows. Using DashMap is therefore necessary for this case to maintain efficiency at scale and enable quick lookups by unique identifiers.
+
+> 3. When programming using Rust, we are enforced by rigorous compiler constraints to make a thread-safe program. In the case of the List of Subscribers (SUBSCRIBERS) static variable, we used the DashMap external library for thread safe HashMap. Explain based on your understanding of design patterns, do we still need DashMap or we can implement Singleton pattern instead?
+
+The Singleton pattern and DashMap serve complementary purposes rather than being alternatives. The lazy_static macro already provides Singleton functionality by ensuring only one instance of the collection exists with global access.
+However, Singleton alone doesn't address thread safety concerns with concurrent access. DashMap specifically handles safe concurrent access to the HashMap, preventing race conditions and other concurrency issues. Therefore, both are needed: the Singleton pattern (via lazy_static) prevents redundant instantiation, while DashMap ensures thread-safe operations on the shared resource.
+
 #### Reflection Publisher-2
 
 #### Reflection Publisher-3