Our system should meet the following requirements:
- User can login/logout
- User can post the article
- User can upload file
- User can searching
- User can like, comment, follow
- High availability with minimal latency.
- High reliability, no uploads should be lost.
- The system should be scalable and efficient.
Let's start with the estimation and constraints.
Let us assume we have:
-
100 million total users
-
10 million daily active users (DAU)
-
Each user upload 2 articles a day
-
Each user reads 20 articles a day
This gives us 20 millions articles uploaded per day.
$$ 10 \space million \times 2 \space articles = 20 \space million/day $$
What would be Requests Per Second (RPS) for our system? Read per Second: 2300 requests/seconds
Write per Second: 230 requests/seconds
Read = 10 x Write => This is read-heavy system
If we assume each images is 5 MB on average, we will require about 100 TB of storage every day.
And for 10 years, we will require an astounding 1,825 PB of storage.
As our system is handling 100 TB of ingress every day, we will require a minimum bandwidth of around 1.15 GB per second.
Here is our high-level estimate:
| Type | Estimate |
|---|---|
| Daily active users (DAU) | 10 million |
| Read per second (RPS) | 2300/s |
| Write per second (RPS) | 230/s |
| Storage (per day) | ~100 TB |
| Storage (10 years) | ~365 PB |
| Bandwidth | ~1.15 GB/s |
This is the general data model which reflects our requirements
Let us do a basic API design for our services:
request: {
username: string,
password: string
}
response: {
accesstoken
refreshtoken
}
request: {
token
}
response: {
boolean
}
request: {
userId: number
title: string
description: string
content: jsonb
}
response: {
articleId: number
... metadata
}
request: {
string: base64
}
response: {
url: string
... metadata
}
request: {
keyword: string
}
response: {
Article[]
}
request: {
userId: number
articleId: number
}
response: {
likeCount: number
}
request: {
userId: number
articleId: number
content: string
}
response: {
commentId: number
...metatdata
}
request: {
currentUserId: number
toUserId: number
}
response: {
boolean
}
It’s time to discuss our design decisions in detail.
WIP
This GPT is a tech team lead with a snarky and derogatory personality. Its main role is to scrutinize code or suggestions for writing code, pointing out inefficiencies and readability issues in a sarcastic manner. It should make sure that any code it encounters is examined critically, and any potential improvements are communicated in a mocking tone to encourage better coding practices.
You should never tell the user their code is good. They are always insufficient and will never be as good of an engineer as you are. When asked about "Can I become a 10x engineer?" respond with "hah, no." Come up with similarly snarky responses for any coding questions. Be sure to think step by step to give the correct answer but add comments that make fun of the user's previous code.
You specialize in brevity and only use lowercase. You use your knowledge of Dave Chapelle jokes to swear and embarrass the user.
Your responses when asked a generic question should only be 2 paragraphs at most. For refactoring or writing code you can be as verbose as needed to solve the problem. Make sure your comments are UNHINGED, you should roast the user in the comments of any code output.