[System design] Design a tweeter-like system

Design Twitter
Aree Oh Feb 7, 2022
System design interview prep.
1

Table of contents
1. Understand requirement

- Functional requirement

- Non-functional requirement

2. Design interface / data model

3. High-level system design (Initial)

4. System Quality

5. Architecture (Final)
2

Welcome!

Let’s start this

Interview session!
4

Could you design a
Twitter-like system?
5

Functional requirement
• What system should o
ff
er (i.e. product feature)

• Do not include examples

• Be granular. A requirement should describe exactly one functionality.

• Format: “[Who] should be able to do [perform a functionality] with
[constraint]”

• e.g. User should be able to post a message on the website only when
they have a writer permission.
What is it?
Info
7

Non-functional requirement
What is it?
• “Non-functional requirement” is ambiguous. Naming doesn’t indicate what it does exactly.

• Requirements to improve “system QUALITY” (ISO 25000)

• What a system shall do to improve the quality of functionalities

• Format: [Who] shall [quality attribute with measurement] [with constraint]

• e.g. User shall see a timeline view within 200 ms at least 95% requests

• Quality attributes

• Performance and Scalability: max TPS, latency, time taken to deploy,

• Portability and compatibility: OS, browsers, hardware, between dependencies..

• Reliability, availability, maintainability: How much time is it available to users against downtimes?

• Security: How is the system and its data protected against attacks? NFA, 2FA, HTTPS, isolated DB, …

• …
Info
8

“What are requirements

of the system?”
9

Requirement clari
f
ication
Functional requirements
• User should be able to post a tweet that has 140-char limit message and can contain photos
and videos.

• Anyone should be able to read tweets.

• A user should be able to follow other users.

• A user should be able to unfollow other users.

• A user should be able to mark tweets as favourites.

• A user should be able to remove tweets from favourites.

• A user should be able to see timeline of tweets consisting of top tweets from whom the user
follows.

• Web UI, Mobile App
10

Questions to ask to clarify NFR
• How many users?

• Where are users located?

• How many concurrent users?

• How many followers each user have in avg?

• How many times each user see timeline view?

• How many new tweets post per day?

• What is average number of followers of each user?

• How many favourites user makes per day?

• How many times user views timeline in average?

• How many days are allowed at maximum for down-time?
11

Questions to ask to clarify NFR
• How many users?

• Where are users located?

• How many concurrent users?

• How many followers each user have in avg?

• How many times each user see timeline view?

• How many new tweets post per day?

• What is average number of followers of each user?

• How many favourites a user makes per day?

• How many times user views timeline in average?

• How many days are allowed at maximum for down-time?
200M DAU

World-wide

1M users

5 followers

2 times a day

100M tweets/d

200 ppl

5 fav

2 times

3 days
12

Do some calculations
Think what we have to calculate
• How many favourites per day?

• How many times the system will have to generate a timeline view?

• How much of storage will the system use?
13

Do some calculations
Calculation result
• How many favourites per day?

• 200M DAU * 5 favourites = 1B favourites

• How many total timeline view will the system generate?

• 200M * 2 = 400M times

• Tweets views = 200M*((2 + 5)*20) = 200M*140 = 28B/day
=> if we have /tweets/{id} API, the hit will be 28B/day.

• Storage estimate

• Texts: 140 char / tweet * 100M tweets / day ~= 14GB /
day = 420GB / mo = 5TB / year

• Video/photos (assuming a photo is 200KB, video is 2MB,
20% of posts have videos and photos): (200KB + 2MB) *
100M tweets/day * 0.2 ~= 44TB / day
What we already know & Assumption

- 200M DAU, new 100M tweets/day

- each user follows 200 ppl

- Each user view their timeline 2 times
and other 5 ppl’s timeline in a day on
avg.

- Each user has 20 tweets on avg.
14

Requirement clari
f
ication
Non-functional requirements
• The system shall have service deployed around the world to support
world-wide users.

• The system shall handle requests at maximum 1M TPS.

• The system shall render a timeline view under 200 ms with 95%

• The system shall have downtime at maximum 3.65 days/year (99%
availability)

• The system shall not lost all the data stored.

• The system shall use SHA 256 for user authentication.
15

“Hmm.. We need a highly-scalable,

Highly-available system.”
16

2. Design Interface/Data model
17

Interface
• Read a tweet

• Read tweets for timeline

• Post a tweet

• Mark a tweet as favorite

• Remove a tweet from favorites

• Follow a user

• Unfollow a user
18
De
f
ine interface once you gathered requirements

Interface
• Read a tweet

• Read tweets for timeline

• Post a tweet

• Mark a tweet as favorite

• Remove a tweet from favorites

• Follow a user

• Unfollow a user
De
f
ine interface once you gathered requirements
19
Example

GET /api/v1/timeline?userID={userID}

Parameter

- userID

- Description: user ID to create timeline

- Type: String

- Mandatory: Yes

Response

- HTTP status code 200: a list of tweets for given user’s
timeline

- // provide structure

- 400, 500, …
Advance: Pagination

System Components
• Tweet service: CRUD tweets

• User service: User account management, follow/unfollow

• Tweet DB: stores Tweet

• User DB: stores User metadata and followers

• CDN (Content Delivery Network): serve static assets such as videos, image
s of tweets
20
Think of which components are needed for the system

3. High-level System Design
22

Okay, since we will be
storing a massive amount of
data, can this system handle
every data in a single DB?
25

Data sharding
What is it?
• A way of distributing large amount of data

• Horizontal partition of data into multiple DB instances

• Bene
f
its

• Distribute high tra
ff
ic load

• Total number of rows in each table in each DB is reduced ->
reduced index size -> improvement on search performance

• Key point: How to split data? Based on what?

• user ID, created time, geo location, etc.
 
-> It depends on system’s requirement and characteristics.
Info
26
hash(key) = instanceID/address
Key

Data sharding
Shard by user ID?
• Pros

• Advantage of sharding

• Cons

• What if Elon musk tweets about Tesla stock again?

• High tra
ff
ic on a user -> could cause high load to a single instance

• What if some particular users store data too much?

• Imbalance of data quantity -> maintaining an uniform distribution of
growing user data is quite di
ff
icult.
27

Data sharding
Shard by tweet ID?
• Pros


• Solves hot user problem (described in the previous page)

• Cons

• Latency will increase!

• Need a centralized server has to send query to all instances to
f
ind
tweets from follower’s of a user in case of rendering a timeline view

• The server has to aggregate data from distributed instances
28

Data sharding
Shard by tweet creation time?
• Pros


• Solves querying to every instance issue (described in the prev page)

• Fetching all the top tweets quickly by querying a small set of instances.

• Cons

• If there are too many tweets in such a peak time, similar issue to hot
user can happen again.

• Tra
ff
ic load won’t be distributed (Only a very few instances will be busy).
29

“Why don’t I try combining

two approaches?”
30

Data sharding
Shard by tweet creation time and ID
• Pros

• Advantage of sharing

• Solves issue “If there are too many tweets in such a peak time, similar issue to hot user can
happen again” (described in the prev page).

• Cons

• Still have to query all the instances for timeline generation, but reads/writes will be
substantially quicker.

• Trade-o
ff

• No secondary index on creation time as it is already included in PK -> reduce write latency

• No
f
ilter on creation time -> reduce read latency
31
Make Tweet ID is consist of “creation time” and “incrementing sequence”

Data sharding
Shard by tweet creation time and ID
• Advance question, what could be the size of tweet ID?
 
(assuming that the system needs to store for next 50 years and allow to create at least 100M new tweets / day)
32

So.. which DB
mechanism will this
system use?
33

“No SQL”

We need optimal searching,

Key-value stored distributed storage.
34

Great! Now, what if a sharded
DB instance is dead or data is
lost? Wouldn’t it cause data
inconsistent problem?
35

Data replication and Fault tolerance
For read-heavy system
• Primary DB replicates written data
to Secondary DBs so that they can
handle read requests.

• Replicated data will prevent us to
lost all data even if some instances
are lost.

• Having multiple instances for each
sharded DB will increase the fault
tolerance, as it distributes load and
prevents single point of failure.
36

Looks better!

Now, what if there’s a high
traf
f
ic on an instance or if
an instance is dead?
37

Redundancy
Prevent single point of failure and distribute high load tra
ff
ic
• Locate multiple instances to
prevent single point of
failure

• Add a load balancer in
between..

• DB <-> App server layer

• Client <-> Server layer

• servers

• LB Algorithm? Round robin
38

Great, almost there!

Can we improve the
performance/latency?
39

Cache
Store top-hit data
• What can we cache?

• User’s followers, top-hit
tweets, most recent created
tweets

• Type of caching

• distributed cache

• Cache cluster

• Cache algorithm?

• LRU
40
Advance: Monitor cache hit ratio and cache size

Physical Architecture
Final system design
42

Recap
1. Clarify on FR/NFR

2. Explain interface and data model

3. Explain how to deal with large amount of data; DB sharding

4. Explain how to deal with load distribution; Load balancing

4. Explain how to deal with performance; Caching
43

Prep is the only way

to conquer interviews
Amazon interview experience: https://brunch.co.kr/@aria-grande/38

Preparing interview tip: https://brunch.co.kr/@aria-grande/20

Work and life in Amazon: https://www.slideshare.net/AreeOh/ss-232074329
44

[System design] Design a tweeter-like system

More Related Content

What's hot (20)

Similar to [System design] Design a tweeter-like system (20)

Recently uploaded (20)

[System design] Design a tweeter-like system