jianminchen/AWS cloud - system design

## AWS cloud - system design
19:43 -> 20:13

1) Requirements
What information are we storing? - Images, videos and PDF files. Large files.
What is the purpose of our service? - Files come in, we process it and then we save it.
Data Processing - It's very quick work.
Read heavy or write heavy - Read heavy.
How many people will use our serivce on a daily basis? - 40M users.
How long will we store the files - We store the files forever, but can purge them as necessary.


2) Estimates
Traffic Estimates
a) Writes
Let's assume about 10% of our DAUs are uploading a new file.
Let's assume they upload just one file, and that file 10MB.
4M writes per day.
100K seconds per day.
40 write requests per second.

b) Reads
Let's assume that each user has 100 reads per day.
40M * 100 = 4B reads per day.
100K seconds per day.
4K read requests per second.

Storage Estimates
Each file is 10MB, 4M.
Each day is 40M MB (there's 1M MB in 1 TB), 40TB of information we're storing per day.
Per month that is 40TB * 30 = 1200TB = 1.2PB.

3) Design Considerations
a) Availabilty Patterns:
We need to ensure we maximise availability over all else, we want to keep downtime as low possible.

b) Reliability
We can't to lose any data/files that user's upload.
We have to replicate the files and information information.

c) Consistency
Eventually Consistent System -> We're allowed to have some delay.

d) Latency
We're allowed latency with uploading and viewing the files, esp. really large files.

e) Throughput
Our system support a high throughput reads that are coming into our system.

4) Architectural Diagram  - I cannot hear you.

hello?  I cannot hear you, you can go ahead to draw diagram using webapp. share the link.
ok, should i wait for you to fix your audio?
https://awwapp.com/b/uhm7lrqfdtvdk/
	19:43 -> 20:13

	1) Requirements
	What information are we storing? - Images, videos and PDF files. Large files.
	What is the purpose of our service? - Files come in, we process it and then we save it.
	Data Processing - It's very quick work.
	Read heavy or write heavy - Read heavy.
	How many people will use our serivce on a daily basis? - 40M users.
	How long will we store the files - We store the files forever, but can purge them as necessary.


	2) Estimates
	Traffic Estimates
	a) Writes
	Let's assume about 10% of our DAUs are uploading a new file.
	Let's assume they upload just one file, and that file 10MB.
	4M writes per day.
	100K seconds per day.
	40 write requests per second.

	b) Reads
	Let's assume that each user has 100 reads per day.
	40M * 100 = 4B reads per day.
	100K seconds per day.
	4K read requests per second.

	Storage Estimates
	Each file is 10MB, 4M.
	Each day is 40M MB (there's 1M MB in 1 TB), 40TB of information we're storing per day.
	Per month that is 40TB * 30 = 1200TB = 1.2PB.

	3) Design Considerations
	a) Availabilty Patterns:
	We need to ensure we maximise availability over all else, we want to keep downtime as low possible.

	b) Reliability
	We can't to lose any data/files that user's upload.
	We have to replicate the files and information information.

	c) Consistency
	Eventually Consistent System -> We're allowed to have some delay.

	d) Latency
	We're allowed latency with uploading and viewing the files, esp. really large files.

	e) Throughput
	Our system support a high throughput reads that are coming into our system.

	4) Architectural Diagram - I cannot hear you.

	hello? I cannot hear you, you can go ahead to draw diagram using webapp. share the link.
	ok, should i wait for you to fix your audio?
	https://awwapp.com/b/uhm7lrqfdtvdk/