diff --git a/README.md b/README.md
index 3043f06d471f2933c5a98c71ad06b7d900d6812c..d7bb31b92280c891422a07a68aff4c09a5dfddf3 100644
--- a/README.md
+++ b/README.md
@@ -78,6 +78,26 @@ This is the place for you to write reflections:
 
 #### Reflection Publisher-1
 
+##### Interface vs Struct in Observer Pattern
+
+According to the Head First Design Patterns' description on Observer pattern, the observer (which in this case, `Subscriber`) is defined as an interface. However, in our implementation of Bambangshop, `Subscriber` is defined as a concrete struct rather than a trait.
+
+The need to use trait depends on our requirements:
+
+- **Struct** - This implementation works well if the subscribers are designed to have the same behaviour and properties.
+
+- **Trait** - This implementation works well if several types subscriber are made and each have different implementations.
+
+Bambangshop's notification system is rather simple, all subscribers have a URL which acts as a media for them to receive notifications through HTTP requests. Therefore, the use of a singgle struct is considered sufficient.
+
+##### Vec vs DashMap for Storing Subscribers
+
+Bambangshop implementation's uses `DashMap` to store subscribers with their URLs as keys. It's possible to utilize `Vec` instead of `DashMap`, however it adds more work as we need to ensure the URLs are unique before storing it into the `Vec`. `DashMap`, like other dictionaries, enforce uniqueness, and the keys of DashMap required to be unique. In conclusion, it's possible to use Vec, however it's best to use DashMap.
+
+##### Thread Safety with DashMap vs Singleton Pattern
+This implementation utilizes both DashMap and Singleton pattern (lazy_static). Both plays an important role in this case, where DashMap allows thread-safe, optimal performance, access to the database and the singleton pattern allows the creation of an instance only when it's requested.
+
+
 #### Reflection Publisher-2
 
 #### Reflection Publisher-3