diff --git a/README.md b/README.md
index 7e0fc90a6f1204f027d6bd86f449e2de09b46e7c..8d43d46d69818903bf31e2adc7fd976018028731 100644
--- a/README.md
+++ b/README.md
@@ -83,6 +83,13 @@ You can install Postman via this website: https://www.postman.com/downloads/
 This is the place for you to write reflections:
 
 ### Mandatory (Subscriber) Reflections
+> In this tutorial, we used RwLock<> to synchronise the use of Vec of Notifications. Explain why it is necessary for this case, and explain why we do not use Mutex<> instead?
+
+RwLock<> is necessary in this case because we need to allow multiple readers to access the Vec of Notifications concurrently while ensuring that only one writer can modify it at a time. This is important for performance, as it allows multiple threads to read notifications without blocking each other. On the other hand, using Mutex<> would block all readers when a writer is modifying the data, which could lead to performance bottlenecks in scenarios with high read concurrency.
+
+> In this tutorial, we used lazy_static external library to define Vec and DashMap as a “static” variable. Compared to Java where we can mutate the content of a static variable via a static function, why did not Rust allow us to do so?
+
+Rust enforces strict ownership and borrowing rules to ensure memory safety and prevent data races. Unlike Java, where static variables can be mutated directly via static functions, Rust requires explicit synchronization mechanisms like `RwLock<>` or `Mutex<>` to safely mutate shared static data. This design choice ensures that access to shared data is always thread-safe, even in concurrent environments. By using libraries like `lazy_static`, we can initialize static variables in a controlled manner while adhering to Rust's safety guarantees.
 
 #### Reflection Subscriber-1