bytebytegohq / system-design-101 Goto Github PK

I think the git rebase diagram is not correct:

After rebasing the feature branch on master, the master branch does not change (still pointing to D), and feature branch is still pointing to G.

Commit E is now based on D in stead of B which is already correct in the diagram

https://github.com/chihyanghsu0805/system-design-101/tree/main#http-status-codes

It should be Successful

file path: images/how-to-learn-sql.jpg

RIFHT JOIN should be RIGHT JOIN

https://github.com/sky-L/system-design-101-zh/tree/main

This should be /orders/456

https://colab.research.google.com/drive/1gPKnkIXaTDpQqFVWSOs1kh71o1t33thP?usp=sharing

In architectural patterns, e.g. MVP, MVVM, etc.
Let's take MVP.

• to better convey the idea of MVP (and why it had limitations, leading to other patterns), "View" box should be show as multiple boxes. That is, there many views and one controller. (I think if two View boxes drawn, with one behind the other, it will avoid overcrowding of the diagram).

There is a typo in the HTTP status codes message - here

I am opening a PR with the fix.

I want to do a Traditional Chinese translation based on #54 and would like to tweak some terminology and create a README-zh_hant.md.

Follow: https://github.com/ByteByteGoHq/system-design-101/blob/main/translations/TRANSLATIONS.md

Hello, I think I found an issue on the first image Communication Protocols!

Websocket, as described are:

Real-time, bidirectional, persistent connections

Hence the connection should be represented as a bi-directional arrow in order to represent the data flow.
It seems that the represented diagram would be more accurate for SSE (Server-Sent Events) which are uni-directional message channels which data-flow is in the exact direction represented by this diagram.

May I know Is that possible shared original image in this repository?

Because I found there are some typo in images, if author can share the original image we can fix the typo easier :)

In the diagram under "How does gRPC work?" "gRPC Runtime" is written as "gPRC Runtime" in both "Order Service" and "Payment Service"

Please add some resources on designing Notification Systems

PR: #57

subscribe on web https://blog.bytebytego.com/ show below
{"error":"Please enable JavaScript to subscribe to this newsletter."}

Resource code Web DevOps

very good work
is it possible generate epub version to read in kindle or other ebook

Hello. Thank you for this valuable repository.
I had a question; is the content in the repository sourced from the free content on the ByteByteGo website, or does it include premium materials as well?

I noticed that the README.md is too big.

What if it was possible to have all the content structured in separate .md files inside a system-design-101-content parent directory?

Here is an example from the roadmap.sh repository.

That way we could have each topic separately with its own subtopics and own pictures. Cause I saw that even the images directory has all images in the same place instead of grouping related images depending on topics in separate directories.

A lot easier for contributors to fix anything that need to be fixed or add anything to any topic... and even for readers.

I will think about an easy way to "implement" that and I am open to work on it.

Of course, 😆

Originally posted by @Adawntoremember in octocat/Spoon-Knife#33502 (comment)

The picture you drew is very beautiful. May I ask which drawing software you used to create it?

#10 - here is the relevant pull request
Not sure if this was intended, but I suggest either adding a period or an "and" between these phrases.

This has not mentioned the registration center yet.

In this part of the README file, there is a typo in Micorservices. It should be Microservices.
https://github.com/ByteByteGoHq/system-design-101#rest-api-vs-graphql

Images are not getting loaded

This is a fantastic repo. I love how you have boiled things down so well.

I suggest you be careful about using domains you do not own in your examples. For instance, this uses [mysite.com](https://github.com/ByteByteGoHq/system-design-101#url-uri-urn---do-you-know-the-differences uses) as an example domain.

According to RFC 2606, using a domain outlined specifically as an example is more appropriate.

Using a domain line example.com would still keep the very high quality of diagrams and information you have and reduce potential unintended consequences like induced spam if someone owns that domain.

PR: #63

Any chance you could cover some of the cncf tools?

In particular, I’ve been trying to understand gloo + envoy + istio, but most tutorials just get into yaml way too quickly and I glaze over.

Thank you for putting this together! I think it’s going to be super helpful to me as a teaching resource. You’ve got all the main points to cover, a killer diagram, and I can answer all the questions that students have that aren’t in the diagram! Bravo!

Typo in CI/CD Pipeline Explained in Simple Terms graph. It should be "or" instead of "of"

"Every step is triggered one after the other of or in parallel, thus called as pipelines"

"stadndards" is used twice in the "Scalability" section of the diagram.
https://github.com/ByteByteGoHq/system-design-101/blob/main/images/monorepo-microrepo.jpg

progress here.
https://github.com/DeadIntegral/system-design-101/blob/docs/transalte-kr/translations/README-kr.md

In the "Session, Cookie, JWT, Token, SSO, and OAuth 2.0 Explained in One Diagram", you mentioned Implicit Grant as recommended grant type solution for native.

For security reasons, you should change the flow recommended for native application to "Authorization Code Flow" and add the PKCE extension for both the web app and native app as well.

"the use of the Implicit Flow with native apps is NOT RECOMMENDED"
Source: https://datatracker.ietf.org/doc/html/rfc8252

I don't know how you make your image but if I can help more, do not hesitate.

In the provided documentation under the "Development" section of the Pre-Production phase (Microservice architecture), there appears to be a misunderstanding in classifying frontend and backend technologies. Specifically, it incorrectly lists "Node.js or React" as popular choices for frontend development. This needs correction to accurately reflect common practices and technology use in microservices architecture.

Detailed Analysis:

1. Incorrect Classification:

   • Node.js is a runtime environment that is primarily used for backend development. It allows developers to use JavaScript to write server-side code, making it popular for building scalable and efficient backend services in microservices architecture.
   • React is a JavaScript library used for building user interfaces (frontend). React is not typically used for backend development.

2. Correct Classification:

   • Frontend Development:
     • Technologies commonly used: React.js, Angular, Vue.js.
     • Purpose: Building the user interface and client-side logic.
   • Backend Development:
     • Technologies commonly used: Node.js, Java, Python, Go, .NET.
     • Purpose: Handling server-side logic, database interactions, and API endpoints.

Suggested Changes:

The corrected text should accurately separate frontend and backend technologies, reflecting their actual use cases in microservices development.

Proposed Revision:

Development - For frontend development, popular technologies include React.js, Angular, and Vue.js. For backend development, common choices are Node.js, Java, Python, Go, and .NET. Additionally, configurations in the API gateway need to be updated according to the API definitions.

Hi.
First of all, thank you. I always enjoy reading your newsletter for the quality content.

I was wondering if you would consider allowing other people to contribute translations?

I would like to translate it into Korean if possible.

Hi,

I think https://nx.dev/ should be referenced here as Nix has nothing to do with monorepo management. If so, the image would need a logo change as well

Hi,

I have some comments for the section on effective REST API design:

1. Use the same casing method
You use camel-case in most variable names except the sort_by. It would be better as sortBy to follow the conventions.

2. Skip the action from URL path
The "Idempotency" example shows a good path POSTS /carts without any action name.
But the cart example URL contains the action name. It is unnecessary because the POST method defines the action.

So I recommend changing it to
POST /carts/123/items
{ itemId: "321" }

By the way, nice collection, good job!

Regarding: password storage

I feel that simply saying "hash" here is a little... irresponsible. Without mention of actually having some kind of work factor/key derivation/key stretching (owasp, wiki: key derivation, wiki: key stretching) it seems like fairly poor advice. Recommending only "using a salt" seems entirely insufficient.