diff --git a/README.md b/README.md
index becd85a1f0c9778f4409cdfded76cb5311dc50e2..96e778c3cbb8ecd956146819e1f3c8c4d073d7d6 100644
--- a/README.md
+++ b/README.md
@@ -50,13 +50,13 @@ You can install Postman via this website: https://www.postman.com/downloads/
 ## Mandatory Checklists (Publisher)
 -   [v] 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.
+    -   [v] Commit: `Create Subscriber model struct.`
+    -   [v] Commit: `Create Notification model struct.`
+    -   [v] Commit: `Create Subscriber database and Subscriber repository struct skeleton.`
+    -   [v] Commit: `Implement add function in Subscriber repository.`
+    -   [v] Commit: `Implement list_all function in Subscriber repository.`
+    -   [v] Commit: `Implement delete function in Subscriber repository.`
+    -   [v] 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,18 @@ 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?
+
+A trait is used when dealing with different types of subscriber that would require a different implementation, but since all subscriber in bambangshop seems to work in the same way, i.e. receiving notification from a URL, i think a single subscriber struct is enough
+
+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?
+
+A dashmap allow us to access a subscriber by it's url in a constant fast time because it works like a dictionary, meanwhile searching through a vec might require more time if its a long list. therefore it's more effecient although not necessary for this case to use dictionary of dashmap.
+
+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?
+
+As far as i know, dashmap is designed to be thread safe, this means itcan handles multiple access with built in thread protection, meanwhile singleton pattern ensure ONLY ONE instance of the subscriber list exist, singleton pattern is not inherently designed to handle multiple request at the same time, which if done incorrectly would corrupt the data. Therefore with my understandng using dashmap to handle multiple access at the same time for something like the static subscriber is simpler and a safer way to mitigate data corruption due to multiple thread at the same time.
+
 #### Reflection Publisher-2
 
 #### Reflection Publisher-3