System requirements

Functional:

• Post advertisements
• View advertisements
• Edit advertisements
• Delete advertisements

Non-Functional:

• Scalable
• Multiple advertisements posted/edited
• Multiple views on an advertisement
• Consistency prioritized

Capacity estimation

Daily Active users: 1 million

Average Posts per User per Day: 2

Average Edits per User per Day: 1

Average Removes per User per Day: 1

User Row: 17 bytes -> 3 400 000 000 -> 3.4 GB

Advertisement Row: 295 bytes -> 295 000 000 bytes -> 295MB per day -> 107GB per year

User Table:

• UserID (INT) 4 bytes
• First Name (VARCHAR) 9 bytes
• Last Name (VARCHAR) 9 bytes

Advertisement Table:

• AdvertisementID (VARCHAR) 7 bytes
• DateTime (DateTime) 5 bytes
• UserID - FK (INT) 4 bytes
• Price (FLOAT) 4 bytes
• Description (VARCHAR) 20 bytes
• Title (VARCHAR) 20 bytes
• S3 bucket Key (VARCHAR) 255 bytes

API design

External:

• POST:
• /edit
• Body can contain fields to update
• Advertisement ID to update
• Price
• Name
• Title

• /post
• UserID
• Fields for advertisement
• Price
• Description
• Title

• /delete
• Advertisement ID

• GET:
• /getAdvertisement
• Advertisement ID

Database design

Depending on if the user can add additional custom fields to advertisement, may want to switch from SQL to noSQL

In our case because the fields are strictly Price/Name/Title, we can opt for SQL DB

User Table:

• UserID (INT)
• First Name (VARCHAR)
• Last Name (VARCHAR)

Advertisement Table:

• AdvertisementID (VARCHAR)
• DateTime (DateTime)
• UserID - FK (INT)
• Price (FLOAT)
• Name (VARCHAR)
• Title (VARCHAR)

High-level design

User sends request to either post/delete/update advertisement or get an advertisement

Client sends request to API Gateway where authorization and rate limiting happens

Loadbalanced to servers -> Round robin

Application logic from APIs to execute requests

Update DB if needed

Read heavy because a lot more people looking at posts than posting

• Use replicas
• Because we're prioritizing consistency, we can use synchronous updates

If request fails, we can retry (possibly 3 retries) if all attempts fail, we send response letting user know we were unable to make post

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

Trade offs/Tech choices

SQL database for strict fields

NoSQL if we allow user to put in varying number of fields and custom fields

Failure scenarios/bottlenecks

Bottleneck:

• Too many reads -> use replicas to take load primary DB
• Too many post requests (edit,remove,post) -> shard DB in this case we can shard by region
• Can also make sure to have DB replicas, this way if there is failure on a DB we can re-elect another DB as lead DB

Future improvements

Category of advertisement

If user wants to get notification for a specific category of advertisements -> we can add a messaging queue (Kafka)

Can also take user feedback and depending on that, can implement features