Update architecture-diagram.png

[NimJay]

Change Summary

• Update the diagram at docs/img/architecture-diagram.png.
• See new diagram here.
• See old diagram here.

Fixes

1. Typo

• See misspelled RecommendationService in architecture #650.

2. Public Access to Source Files

• There was a comment (from 2019) from a non-Googler (see comment) that requested access to the source files of the diagram. Due to this interest, I've made the Google Slides that I used to create the diagram publicly accessible.

3. Public Access to Source Files

• I've used a white background (for the new diagram) instead of a transparent background for developers using dark mode for GitHub. See problem with existing transparent diagram below:

@ahrarmonsur's Feedback

• Thank you, @ahrarmonsur, for your feedback on the diagram!
• I addressed some of it:
  • "I don't know what to look at first." - I've made the frontend service the focal point. I've bolded "frontend" and added a maroon/pink-ish background.
  • "The 'service' suffix might be redundant." - Suffixes removed!
  • "The edges are too attention-grabbing." - Edges lightened.
  • "Change 'Internet' to 'Client' or 'User'." - Done.
• You also suggested adding icons to each microservice. Overall, I think icons would be valuable, but I've omitted them for these reasons:
  • The effort might not be worth it.
  • It might be hard to find well-matching icons for some of the services (e.g., adservice).
  • Icons might add noise to the overall diagram.
  • I don't think it's super important to communicate the purpose of each microservice.
• Let me know if I missed any other issues you raised. :)

[xtineskim]

this looks clean!! thanks for tackling the issues too!

[github-actions]

🚲 PR staged at http://35.226.58.146

[xtineskim]

This LGTM, but maybe wait for Ahrar's feedback/thoughts!

[bourgeoisor]

This looks much, much easier to read, thank you for this!
Small nit: could you make the arrow from frontend->ad start at the bottom of frontend, and not from the side?
At first glance it looks like there's an arrow from loadgen->ad which took me a while to unsee.
Similarly, could we have the arrows to payment / email also start from the bottom, for consistency?

[github-actions]

🚲 PR staged at http://35.226.58.146

[NimJay]

@ckim328 Thanks for the quick review!

@bourgeoisor Good feedback! Thank you! Arrows fixed. ✅

[ahrarmonsur]

Wow, what a great improvement to the diagram! As the first technical artifact that informs the user of the app's architecture, it is very important to get this right. This revision is much easier to consume at a glance. Great job, @NimJay!! 👏

I have some thoughts, but none of them are blocking:

• To be precise, the User/loadgenerator can communicate over both HTTP and HTTPS. In that case, the technically correct notation would be HTTP(S)
• I would suggest using the a darker shade of grey/black on the borders Service nodes (keep it consistent with the font color, too)
• Should be "Redis cache"
• The arrows from frontend to User/loadgenerator should be bi-directional (..right?)

[bourgeoisor]

Thank you for addressing my comment, this looks amazing!

[NimJay]

Thank you, @ahrarmonsur, for the second round of feedback!

To be precise, the User/loadgenerator can communicate over both HTTP and HTTPS. In that case, the technically correct notation would be HTTP(S)

Good suggestion.
Unfortunately, most tutorials that use Online Boutique just use HTTP — not HTTPS. :(
onlineboutique.dev uses HTTPS but I don't want the diagram to represent onlineboutique.dev because we don't use loadgenerator for it.

I would suggest using the a darker shade of grey/black on the borders Service nodes (keep it consistent with the font color, too)

Good suggestion, but when I tried it out, it seems like the rectangles steal attention away from the text (see slide 2 vs slide 1).

Should be "Redis cache"

Fixed. It's now "cache" — not "Cache".

The arrows from frontend to User/loadgenerator should be bi-directional (..right?)

The frontend never initiates the communication between itself and the user/loadgenerator.
It's always: user/loadgenerator makes a request; frontend responds.
So I'll stick to 1-directional.

Merging.

[github-actions]

🚲 PR staged at http://35.226.58.146