Module 01/iulian

modules/module-01/REFLECTION.md

@@ -4,9 +4,9 @@
 
 # Module 1 — Reflection
 
-**Team name**: **\*\***\_\_\_**\*\***
-**Branch**: `module-01/<team-name>`
-**Submitted**: before Module 2 lesson
+**Team name**: **Iulian - just me**
+**Branch**: `module-01/iulian`
+**Submitted**: Unfortuneltey a bit late 👉👈
 
 ---
 
@@ -22,8 +22,17 @@ You started from a painful monolith. Now you're splitting it into separate servi
 
 Think about it from three angles: the developer who has to change code, the team that has to deploy it, and the user who has to live with its failures. You don't need to cover all three, pick the one that felt most real to you today.
 
-> _Your answer:_
+```
+It solves a problem for the developer who has to change code.
 
+In a monolith, changing the logging logic means opening the same codebase
+that handles login, games, and notifications. You risk breaking something
+unrelated every time you deploy.
+
+With separate services, you change one thing, deploy one thing, and nothing
+else is at risk.
+
+```
 ---
 
 ## 2. Your choice
@@ -34,7 +43,16 @@ Look at your service map. Every arrow between two services is a decision someone
 
 What would break, slow down, or become harder to manage if you merged those two services back together?
 
-> _Your answer:_
+``` 
+The line between activity-service and logging-service.
+
+They both deal with what users do, but for completely different reasons.
+activity-service powers the social feed. logging-service exists because of
+GDPR — it has to check consent before writing anything down.
+
+If I merged them, a bug in the feed logic could accidentally bypass the
+consent check. Two very different responsibilities tangled in one place.
+```
 
 ---
 
@@ -46,7 +64,17 @@ Microservices solve the monolith's problems. But they create new ones.
 
 No need to solve it: just name it honestly. This is exactly the tension the rest of the course is about.
 
-> _Your answer:_
+```
+In the monolith, "did this user consent AND what did they play today" is
+one SQL query joining two tables.
+
+In the distributed design, that data lives in two separate services that
+cannot touch each other's database. A simple question became a distributed
+systems problem.
+
+I don't have a solution yet — I think that's what the rest of the course
+is for.
+```
 
 ---
 

modules/module-01/exercise.md

@@ -26,11 +26,16 @@ A bounded context is a part of the system that has a clear responsibility and ow
 
 For each bounded context you identify, fill in the table:
 
-| Bounded Context | Responsibilities                                         | Owned Entities | Team        |
-| --------------- | -------------------------------------------------------- | -------------- | ----------- |
-| Identity        | Manages who users are, handles registration and profiles | User, Session  | Platform    |
-| Game Library    | _(fill in)_                                              | _(fill in)_    | _(fill in)_ |
-| _(add more)_    |                                                          |                |             |
+## Iulian ##
+
+| Bounded Context | Responsibilities                                         | Owned Entities  | Team        |
+| --------------- | -------------------------------------------------------- | ----------------| ----------- |
+| Identity | Manages who users are, handles registration and profiles | User, Session   | Platform    |
+| Game Library | Manages the game catalog, genres, search and game metadata | Game, Genre, Tag | Catalog  |
+| Activity | Records what users play, follow and rate, serves the social feed | ActivityEvent, Follow, Rating | Social |
+| Logging | Stores GDPR consent status, records activity only for opted-in users | ConsentRecord, ActivityLog | Compliance |
+| Notification | Delivers alerts via push and email, manages notification preferences | Notification, NotificationPreference | Platform |   
+
 
 There is no single correct answer: what matters is that you can justify each row.
 
@@ -45,6 +50,29 @@ For each pair of services that need to communicate, define:
 - **Protocol**: REST or event (async)
 - **Payload**: key fields exchanged
 
+## Iulian ##
+
+**Flow 1**
+
+- **Direction**: client -> gateway -> auth-service
+- **Trigger**: User submits login form
+- **Protocol**: REST (synchronous or how it is written) - Client is waiting for the token
+- **Payload**: {email, password} -> returns {jwt_token}
+
+**Flow 2**
+
+- **Direction**: activity-service -> logging-service
+- **Trigger**: An activity event is recorded
+- **Protocol**: RabbitMQ message - activity-service shouldn't wait or fail if logging is slow
+- **Payload**: {activity_id, user_id, action, game_id, timestamp}
+
+**Flow 3**
+
+- **Direction**: activity-service -> notification-service
+- **Trigger**: A followed froend starts playing
+- **Protocol**: Still a RabbitMQ message - Notification dlelivery can be slow so like this the activity write is not blocked
+- **Payload**: {email, password} -> returns {jwt_token}
+
 Example:
 
 ```
@@ -69,25 +97,40 @@ Draw the full GameHub service map:
 
 This can be a sketch on paper, a whiteboard photo, or ASCII art committed to your branch.
 
+## It is made in DrawIO ##
+
 ---
 
 ## Discussion _(~15 min)_
 
 Three questions to discuss as a team before you leave:
 
+```
 1. Why does `notification-service` use Node.js instead of Python like the rest? What does that tell you about microservices and technology choices?
+
+- Because microservices have the best tools fot your job. Notification delivery involves holding many open connections and Node.js has the event loop (we did this in Server-side JS) which was built for this. Python would work, but Node.js is more natural here. The key insight is that services are isolated enough that a different language in one place doesn't contaminate the others.
+
+
 2. What is the risk of `activity-service` calling `logging-service` synchronously — why might you prefer an async event instead?
+
+- If logging-service is slow, or down, activity-service would be blocked waiting or it would fail. Every user action would feel not-user-friendly, and a logging outage would break the entire activity feature. Using an async event instead, activity-service fires the event and moves on immediately. Logging-service processes it when it can. The two services fail independently (unfortunetley).
+
 3. Why does `logging-service` need a GDPR consent check before recording any activity?
 
+- EU law requires that you have the user's explicit consent before tracking their behavior (GDPR class). If you record first and check later, you've already violated the regulation. Logging-service is the gatekeeper: it receives the activity event, checks its own consent table for that user, and only writes the record if consent exists. The consent data lives in logging-service's database and nobody else owns it.
+
+```
 You do not need to write these answers down — they are warm-up for your REFLECTION.md.
 
 ---
 
 ## Minimum to submit this branch
 
-- [ ] Bounded context table filled in (at least 4 services justified)
-- [ ] At least 3 service contracts defined
-- [ ] Service map committed (sketch, photo, or ASCII)
-- [ ] `REFLECTION.md` completed and committed
+- [x] Bounded context table filled in (at least 4 services justified)
+- [x] At least 3 service contracts defined
+- [x] Service map committed (sketch, photo, or ASCII)
+- [x] `REFLECTION.md` completed and committed
 
 The map does not need to be perfect. It needs to be yours.
+
+