On the Whatsapp system design, you have the following paragraph:

As per our requirements, we also know that around 5 percent of our daily messages (100 million) are media files. If we assume each file is 50 KB on average, we will require 10 TB of storage every day.

When you make the calculation, you show the math as:

100 million * 100 KB

when I was expecting

100 million * 50 KB, given that you said that each file is 50 KB on average

leading to 5 TB of storage instead of the 10 TB you've arrived. What am I missing?

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Additional context

First, I just want to say this is an excellent resource. Thank you for this.

Second, I was curious about the tools used for the clear and concise overview diagrams and ER diagrams (they appear to be two different tools). What tools were used to produce these?

I would just like to clarify about this diagram.
The tables chats and groups have messageId's. As I understand that it is redundant here and should be replaced, for example, by the name of the group or chat.

Is your feature request related to a problem? Please describe.
There is a small mistake in the Sparse Indexing Sectionm,where instead of "records", "index" should be written

Please see above image for reference @karanpratapsingh
Describe the solution you'd like

Additional context

Description

There is an issue with GitHub rendering the content in a \begin{gather*} to \end{gather*} section.

Browser & platform

Browser: Safari Version 15.5 (17613.2.7.1.8), Chrome Version 104.0.5112.101 (Official Build) (x86_64)
OS: macOS Monterey Version 12.4 (21F79)

Steps to reproduce, current behaviour

1. Open the README.md file at the top level.
2. Scroll down to the section at URL Shortener -> High-level design -> URL Encoding.
3. Look at how GitHub renders the following section

Expected behaviour

The GitHub renderer should display the content as it is rendered in VSCode, as in the screenshot below.

Notes

No changes were made to README.md to render it on VSCode.

Very impressive content . I did not know there was a 3 phase commit ;)

wondering if the markdown could be in many folded to make it easier to read.

My use case is when I need to send a link to someone to get them up to speed on a concept. I know the anchors work fine with everything in the current massive readme.md but it’s a bit overwhelming.

the other reason is load time

First of all, great job!
One suggestion I would like to make is to make the font that you use in the images more readable - e.g. make it larger or find another font face.
It would make it easier to read the document directly from the github website.

First of all thanx for this great material.
There is concept of referential integrity used in advantages of normalization .
It will be good if we add small description regarding this (revise karte time baar bar ise bhuul jata hu :{ )
Below is the best article with example i have read so far.

Referential integrity is a concept in relational databases that ensures the consistency and accuracy of data relationships between tables. It enforces rules that maintain the validity of references (foreign key constraints) between related tables. The primary goal of referential integrity is to prevent orphaned or invalid references, ensuring that all foreign key values in child tables reference existing primary key values in parent tables.

Here's how referential integrity is typically enforced:

1. Foreign Key Constraints:

   • Foreign key constraints establish a relationship between a column (or columns) in a child table (referencing table) and a primary key column (or columns) in a parent table (referenced table).
   • The foreign key column in the child table must contain values that exist in the corresponding primary key column of the parent table.
   • If a foreign key constraint is violated (i.e., an attempt is made to insert or update a value in the child table that does not exist in the parent table), the database management system (DBMS) will raise an error, preventing the operation and maintaining referential integrity.

2. CASCADE Options:

   • CASCADE options specify the action to be taken when a referenced row in the parent table is modified or deleted.
   • CASCADE DELETE: If a referenced row in the parent table is deleted, all corresponding rows in the child table are automatically deleted.
   • CASCADE UPDATE: If a referenced primary key value in the parent table is updated, all corresponding foreign key values in the child table are automatically updated.

3. CHECK Constraints:

   • CHECK constraints ensure that values inserted or updated in a column meet specific conditions or criteria.
   • They can be used to enforce additional rules beyond foreign key constraints, such as ensuring that certain values are not inserted or updated in a column.

4. Primary Key Constraints:

   • Primary key constraints define a unique identifier for each row in a table, ensuring that each primary key value is unique and not null.
   • Foreign keys in related tables reference these primary key values, establishing the relationships between tables.

By enforcing referential integrity through foreign key constraints and other mechanisms, databases maintain the integrity, consistency, and accuracy of data relationships, preventing data anomalies and ensuring data reliability.

This covers in depth of all topics, however, it would be great if we can add these:

Is your feature request related to a problem? Please describe.
There are some interesting load balancing solutions like Azure traffic manager (DNS based Load balancer) & Azure frontdoor (Anycast based split tcp global load balancer) . similar ones by GCP & AWS.

Describe the solution you'd like
DNS load balancing mechanism, anycast based split tcp load balancers are worth reading. would you be able to add content / links to these topics as well.

Is your feature request related to a problem? Please describe.

Unable to send the epub file to my kindle

Describe the solution you'd like

Optimize some of the assets to put the file size under 50mb

Additional context

First, thank you for your excellent resource. This resource is very helpful to me for study.

And I have a one question.
Can I translate your resource into korean and post it on my blog?

I think, given that this repository does not have a separate directory for the converted resources,
it seems that it does not want to have any content for the separate translated material.

So I ask you to check if it's okay to post it on my blog.
Of course, I will specify you and the original link of these repository.

Etsy has had some very interesting problems to solve and has well documented blog posts similar to Netflix

Please consider adding Etsy to Next Steps

as above mentioned

The terms "row" and "column" are specific to table-based, relational ("SQL") DBMS. In the sections where DBMS are discussed in general terms, e.g. comparing SQL vs NoSQL systems, using the terms "record" and "field" would be more inclusive. Especially so when referring to records in NoSQL, like in this paragraph:

Whereas in NoSQL, schemas are dynamic. Columns can be added on the fly, and each row (or equivalent) doesn't have to contain data for each column.

Instead, it could read

Whereas in NoSQL, schemas are dynamic. Fields can be added on the fly, and each record doesn't have to contain data for each field.

It could be argued that the terms "record" and "field" apply more loosely in the graph storage context, although a node can be thought of (and often is implemented) as a record, holding "fields" of property or edge meta types.

Key-value stores don't even have the concept of field ("column") at all, since all records are just that — records.

In the end, regardless of the underlying model, all DBMS hold records that tie together one or more closely related pieces of data — fields. Only information laid out in a table layout can have "rows" and "columns".

Just wanted to thank you for the course document. I haven't read through it yet but I already see that you touch on pretty much all important topics.

Well done and keep up!