โฌ๏ธ Main Note
https://docs.google.com/document/d/1-eH_yBUhPpvdizNdblevmtFpXr5XpStC3KgcGywECfU/edit
Email and password data are sent from browser to backend with the request of login-API.
Inside the data base, there is a data table that contains the user log in data. Then it finds out the corresponding data.
--> (ex) Josh 123#1 a@b.com)
When the log in data is found, backend memory saves the user log in data into a variable called "Session". Session is a type of memory-based-data.
Since the user is logged in, every single requests the user sends is requested with session number.
--> For example for payment, the computer should know who(which id/user) is trying to pay the money.
When the traffic gets higher, meaning that when lots of people start to join in, backend cannot handle all the requests at once. Backend responds one at a time.
CPU helps backend computer to solve all the requests in a short time.
--> It's a memory that saves left waiting users or sending data, etc.
--> Scale-up => Increasing CPU
Even iof there are bunch of backend computer, the number of API is the same. So it is possible to expand backend computer.
--> Scale-out => Expanding by copy and pasting.
1
It is still hard to divide those copied backend computers.
What if Josh went to different browser because the previous browser was full? ( people 10/10)
--> The new browser isn't the one where Josh logged in, so scale-out is impossible.
Stateful => Each backend computer having its own state!
To solve this problem, Login Session should be saved inside the data base.
--> Literally the log-in data are saved inside the data base.
--> For data base, it doesn't matter how large the database are expanded.
--> Stateless
2
Then What's the difference between expanding backend copmuter and expanding data base?
Q. How to solve these problems?
โก๏ธ ๐งฉ Data Partitioning
Just think as dividing the table into pieces.
//DB๋ฅผ ๊ธ๋๋ค = ๋์คํฌ์์ DB๋ก๋ถํฐ ๋ฐ์ดํฐ๋ฅผ ๊บผ๋ด์จ๋ค
<JSON Web Token>
2 Ways to encode =>
abcd -> 1234
273719 -> 7 7 9
7 7 9