Skip to content

i finished the reflection.md questions #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
njfred5 wants to merge 1 commit into
base: module-4
Choose a base branch
from
Open

i finished the reflection.md questions #16

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions modules/module-04/REFLECTION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Module 4 — Reflection

**Team name**: _______________
**Team name**: ______fred_________
**Branch**: `module-04/<team-name>`
**Submitted**: before Module 5 lesson

Expand All @@ -20,7 +20,7 @@ Think about what happens under load, or when notification-service is temporarily

> *Your answer:*

---
---so basically activity-service before had to wait for everything to finish before it could send back a response to the user, now it just drops the message in the queue and immediately says "ok done" without waiting for anyone to pick it up. this means if notification-service is super slow or even completely down, the user still gets a fast response and the activity still gets saved. notification-service on the other side can just process messages whenever it wants, if it gets 1000 notifications at once it can go through them one by one at its own speed instead of crashing because too many requests came in at the same time.

## 2. Your choice

Expand All @@ -32,7 +32,7 @@ Think about what happens if notification-service is slow, or crashes mid-message

> *Your answer:*

---
---if we called notification-service directly over HTTP like we did for user validation, then if notification-service crashes in the middle of sending, the whole request fails or hangs. also if its slow, the user has to wait longer just because of notifications which has nothing to do with saving the activity. the broker fixes this because the message sits in the queue safely even if notification-service is down, when it comes back up it just picks up where it left off. with direct HTTP if the service is down the message is just gone.

## 3. The tradeoff

Expand All @@ -44,6 +44,6 @@ What visibility do you lose when you go async?

> *Your answer:*

---
---yeah this is the annoying part of async, you basically have no idea if the notification actually got delivered or not. from the user side they might just never see the notification and have no idea why. from the developer side you would have to check the RabbitMQ UI manually or look at logs in notification-service to see if messages are being consumed. you lose the immediate feedback you get with REST where you know right away if it worked or failed. to fix this properly you would need to add some kind of logging or monitoring that tracks when a message was picked up and processed, but that adds more complexity.

*Keep this file. You will refer back to it during the oral presentation.*