System Design

Vinh Hoang
Single Server Setup
Database
Load Balancer
 Database Replication

• Better performance
• Reliability
• High availability
Load Balancer And Database Replication
Cache
CDN
System with Cache and CDN
Stateful Vs. Stateless
System with Stateless Architecture
Data Centers
Message Queue
Vertical Scaling Vs. Horizontal Scaling
 Case Studies – New Feed System

Candidate: Is this a mobile app? Or a web app? Or both?

Interviewer: Both.
Candidate: What are the most important features for the product?
Interviewer: Ability to make a post and see friends’ news feed.
Candidate: Is the news feed sorted in reverse chronological order or a particular order? The particular order
means each post is given a different weight. For instance, posts from your close friends are more important
than posts from a group.
Interviewer: To keep things simple, let us assume the feed is sorted by reverse chronological order.
Candidate: How many friends can a user have?
Interviewer: 5000
Candidate: What is the traffic volume?
Interviewer: 10 million daily active users (DAU)
Candidate: Can feed contain images, videos, or just text?
Interviewer: It can contain media files, including both images and videos.
System with Message Queue
First High Level Design
Design Deep Dive
 Designing a URL Shortening service like TinyURL

• Functional Requirements:
1. Given a URL, our service should generate a shorter and unique alias of it. This is called a short link.
This link should be short enough to be easily copied and pasted into applications.
2. When users access a short link, our service should redirect them to the original link.
3. Users should optionally be able to pick a custom short link for their URL.
4. Links will expire after a standard default timespan. Users should be able to specify the expiration
time.
• Non-Functional Requirements:
1. The system should be highly available. This is required because, if our service is down, all the URL
redirections will start failing.
2. URL redirection should happen in real-time with minimal latency.
3. Shortened links should not be guessable (not predictable).
• Extended Requirements:
1. Analytics; e.g., how many times a redirection happened?
2. Our service should also be accessible through REST APIs by other services.
 Capacity Estimation and Constraints

Traffic estimates: Assuming, we will have 500M new URL shortenings per
month, with 100:1 read/write ratio, we can expect 50B redirections during the
same period:
100 * 500M => 50B
What would be Queries Per Second (QPS) for our system? New URLs
shortenings per second:
500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/s

Considering 100:1 read/write ratio, URLs redirections per second will be:
100 * 200 URLs/s = 20K/s
 Capacity Estimation and Constraints

Storage estimates: Let’s assume we store every URL shortening request (and
associated shortened link) for 5 years. Since we expect to have 500M new
URLs every month, the total number of objects we expect to store will be 30
billion:
500 million * 5 years * 12 months = 30 billion

Let’s assume that each stored object will be approximately 500 bytes (just a
ballpark estimate–we will dig into it later). We will need 15TB of total storage:
30 billion * 500 bytes = 15 TB
 Capacity Estimation and Constraints

Bandwidth estimates: For write requests, since we expect 200 new URLs every
second, total incoming data for our service will be 100KB per second:
200 * 500 bytes = 100 KB/s

For read requests, since every second we expect ~20K URLs redirections, total
outgoing data for our service would be 10MB per second:
20K * 500 bytes = ~10 MB/s
 Capacity Estimation and Constraints

Memory estimates: If we want to cache some of the hot URLs that are
frequently accessed, how much memory will we need to store them? If we
follow the 80-20 rule, meaning 20% of URLs generate 80% of traffic, we would
like to cache these 20% hot URLs.

Since we have 20K requests per second, we will be getting 1.7 billion requests
per day:
20K * 3600 seconds * 24 hours = ~1.7 billion

To cache 20% of these requests, we will need 170GB of memory.

0.2 * 1.7 billion * 500 bytes = ~170GB
 Capacity Estimation and Constraints

High-level estimates: Assuming 500 million new URLs per month and 100:1
read:write ratio, following is the summary of the high level estimates for our
service:
 System Api

createURL(api_dev_key, original_url, Parameters:

custom_alias=None, user_name=None, api_dev_key (string): The API developer key of a
expire_date=None) registered account. This will be used to, among
other things, throttle users based on their
allocated quota.
original_url (string): Original URL to be
shortened.
custom_alias (string): Optional custom key for
the URL.
user_name (string): Optional user name to be
used in the encoding.
expire_date (string): Optional expiration date
for the shortened URL.
 System Api

deleteURL(api_dev_key, url_key) Where “url_key” is a string representing the

shortened URL to be retrieved; a successful
deletion returns ‘URL Removed’.
Database Schema
Basic Design
Design with Cache
Summary
 Case study – Design Instagram

• Functional Requirements
1. Users should be able to upload/download/view photos.
2. Users can perform searches based on photo/video titles.
3. Users can follow other users.
4. The system should generate and display a user’s News Feed consisting of top photos from all
the people the user follows.
• Non-functional Requirements
1. Our service needs to be highly available.
2. The acceptable latency of the system is 200ms for News Feed generation.
3. Consistency can take a hit (in the interest of availability) if a user doesn’t see a photo for a
while; it should be fine.
4. The system should be highly reliable; any uploaded photo or video should never be lost.
 Capacity Estimation and Constraints

• Let’s assume we have 500M total users, with 1M daily active users.
• 2M new photos every day, 23 new photos every second.
• Average photo file size => 200KB
• Total space required for 1 day of photos
2M * 200KB => 400 GB
• Total space required for 10 years:
400GB * 365 (days a year) * 10 (years) ~= 1425TB
High Level System Design
Database Schema
Database Estimation

User: Assuming each “int” and “dateTime”

is four bytes, each row in the User’s table
will be of 68 bytes:

UserID (4 bytes) + Name (20 bytes) +

Email (32 bytes) + DateOfBirth (4 bytes)
+ CreationDate (4 bytes) + LastLogin (4
bytes) = 68 bytes

If we have 500 million users, we will need

32GB of total storage.
500 million * 68 ~= 32GB
Database Estimation

Photo: Each row in Photo’s table will be of 284

bytes:
PhotoID (4 bytes) + UserID (4 bytes) +
PhotoPath (256 bytes) + PhotoLatitude (4
bytes) + PhotoLongitude(4 bytes) +
UserLatitude (4 bytes) + UserLongitude (4
bytes) + CreationDate (4 bytes) = 284 bytes

If 2M new photos get uploaded every day, we

will need 0.5GB of storage for one day:
2M * 284 bytes ~= 0.5GB per day

For 10 years we will need 1.88TB of storage.

Database Estimation

UserFollow: Each row in the UserFollow

table will consist of 8 bytes. If we have 500
million users and on average each user
follows 500 users. We would need 1.82TB
of storage for the UserFollow table:
500 million users * 500 followers * 8
bytes ~= 1.82TB

Total space required for all tables for 10

years will be 3.7TB:
32GB + 1.88TB + 1.82TB ~= 3.7TB
Component Design
Use Case Diagrams

• System Boundary: A system boundary defines the

scope and limits of the system. It is shown as a
rectangle that spans all use cases of the system.
• Actors: An actor is an entity who performs specific
actions. These roles are the actual business roles of
the users in a given system. An actor interacts with a
use case of the system. For example, in a banking
system, the customer is one of the actors.
• Use Case: Every business functionality is a potential
use case. The use case should list the discrete
business functionality specified in the problem
statement.
• Include: Include relationship represents an invocation
of one use case by another use case. From a coding
perspective, it is like one function being called by
another function.
• Extend: This relationship signifies that the extended
use case will work exactly like the base use case,
except that some new steps will be inserted in the
extended use case.
Activity Diagrams And Sequence Diagrams
Class Diagram
Class Diagram
Class Diagram
 Case Study - Design a Hotel Management System

1. The system should support the booking of different room types like standard, deluxe,
family suite, etc.
2. Guests should be able to search the room inventory and book any available room.
3. The system should be able to retrieve information, such as who booked a particular
room, or what rooms were booked by a specific customer.
4. The system should allow customers to cancel their booking - and provide them with
a full refund if the cancelation occurs before 24 hours of the check-in date.
5. The system should be able to send notifications whenever the booking is nearing the
check-in or check-out date.
6. The system should maintain a room housekeeping log to keep track of all
housekeeping tasks.
7. Any customer should be able to add room services and food items.
8. Customers can ask for different amenities.
9. The customers should be able to pay their bills through credit card, check or cash
 Use Case Diagram

• Guest: All guests can search the available

rooms, as well as make a booking.
• Receptionist: Mainly responsible for adding
and modifying rooms, creating room
bookings, check-in, and check-out customers.
• System: Mainly responsible for sending
notifications for room booking, cancellation,
etc.
• Manager: Mainly responsible for adding new
workers.
• Housekeeper: To add/modify housekeeping
record of rooms.
• Server: To add/modify room service record of
rooms.
 Class Diagram

• Hotel and HotelLocation: Our system will support multiple locations

of a hotel.
• Room: The basic building block of the system. Every room will be
uniquely identified by the room number. Each Room will have
attributes like Room Style, Booking Price, etc.
• Account: We will have different types of accounts in the system:
one will be a guest to search and book rooms, another will be a
receptionist. Housekeeping will keep track of the housekeeping
records of a room, and a Server will handle room service.
• RoomBooking: This class will be responsible for managing
bookings for a room.
• Notification: Will take care of sending notifications to guests.
• RoomHouseKeeping: To keep track of all housekeeping records for
rooms.
• RoomCharge: Encapsulates the details about different types of
room services that guests have requested.
• Invoice: Contains different invoice-items for every charge against
the room.
• RoomKey: Each room can be assigned an electronic key card. Keys
will have a barcode and will be uniquely identified by a key-ID.
 Case Study - Design a Library Management System

1. Any library member should be able to search books by their title, author, subject category as well
by the publication date.
2. Each book will have a unique identification number and other details including a rack number
which will help to physically locate the book.
3. There could be more than one copy of a book, and library members should be able to check-out
and reserve any copy. We will call each copy of a book, a book item.
4. The system should be able to retrieve information like who took a particular book or what are the
books checked-out by a specific library member.
5. There should be a maximum limit (5) on how many books a member can check-out.
6. There should be a maximum limit (10) on how many days a member can keep a book.
7. The system should be able to collect fines for books returned after the due date.
8. Members should be able to reserve books that are not currently available.
9. The system should be able to send notifications whenever the reserved books become available,
as well as when the book is not returned within the due date.
10.Each book and member card will have a unique barcode. The system will be able to read
barcodes from books and members’ library cards.
 Use Case Diagram

• Librarian: Mainly responsible for adding

and modifying books, book items, and
users. The Librarian can also issue,
reserve, and return book items.
• Member: All members can search the
catalog, as well as check-out, reserve,
renew, and return a book.
• System: Mainly responsible for sending
notifications for overdue books, canceled
reservations, etc.
 Class Diagram

• Library: The central part of the organization for which this software has
been designed. It has attributes like ‘Name’ to distinguish it from any
other libraries and ‘Address’ to describe its location.
• Book: The basic building block of the system. Every book will have
ISBN, Title, Subject, Publishers, etc.
• BookItem: Any book can have multiple copies, each copy will be
considered a book item in our system. Each book item will have a unique
barcode.
• Account: We will have two types of accounts in the system, one will be a
general member, and the other will be a librarian.
• LibraryCard: Each library user will be issued a library card, which will be
used to identify users while issuing or returning books.
• BookReservation: Responsible for managing reservations against book
items.
• BookLending: Manage the checking-out of book items.
• Catalog: Catalogs contain list of books sorted on certain criteria. Our
system will support searching through four catalogs: Title, Author,
Subject, and Publish-date.
• Fine: This class will be responsible for calculating and collecting fines
from library members.
• Author: This class will encapsulate a book author.
• Rack: Books will be placed on racks. Each rack will be identified by a
rack number and will have a location identifier to describe the physical
location of the rack in the library.
• Notification: This class will take care of sending notifications to library
members.
 Case Study – Design an ATM

• The main components of the ATM that will • The user can have two types of accounts:
affect interactions between the ATM and its 1) Checking, and 2) Savings, and should
users are:
be able to perform the following five
1. Card reader: to read the users’ ATM cards.
transactions on the ATM:
2. Keypad: to enter information into the ATM
e.g. PIN. cards. 1. Balance inquiry: To see the amount of
3. Screen: to display messages to the users. funds in each account.
4. Cash dispenser: for dispensing cash. 2. Deposit cash: To deposit cash.
5. Deposit slot: For users to deposit cash or 3. Deposit check: To deposit checks.
checks.
6. Printer: for printing receipts. 4. Withdraw cash: To withdraw money from
7. Communication/Network Infrastructure: it their checking account.
is assumed that the ATM has a 5. Transfer funds: To transfer funds to
communication infrastructure to communicate another account.
with the bank upon any transaction or activity.
 Use Case Diagram

• Operator: The operator will be responsible for the following

operations:
1. Turning the ATM ON/OFF using the designated Key-Switch.
2. Refilling the ATM with cash.
3. Refilling the ATM’s printer with receipts.
4. Refilling the ATM’s printer with INK.
5. Take out deposited cash and checks.
• Customer: The ATM customer can perform the following
operations:
1. Balance inquiry: the user can view his/her account balance.
2. Cash withdrawal: the user can withdraw a certain amount of cash.
3. Deposit funds: the user can deposit cash or checks.
4. Transfer funds: the user can transfer funds to other accounts.
• Bank Manager: The Bank Manager can perform the following
operations:
1. Generate a report to check total deposits.
2. Generate a report to check total withdrawals.
3. Print total deposits/withdrawal reports.
4. Checks the remaining cash in the ATM.
 Class Diagram

ATM: The main part of the system for which this software has been designed.
It has attributes like ‘atmID’ to distinguish it from other available ATMs, and
‘location’ which defines the physical address of the ATM.
CardReader: To encapsulate the ATM’s card reader used for user
authentication.
CashDispenser: To encapsulate the ATM component which will dispense
cash.
Keypad: The user will use the ATM’s keypad to enter their PIN or amounts.
Screen: Users will be shown all messages on the screen and they will select
different transactions by touching the screen.
Printer: To print receipts.
DepositSlot: User can deposit checks or cash through the deposit slot.
Bank: To encapsulate the bank which ownns the ATM. The bank will hold all
the account information and the ATM will communicate with the bank to
perform customer transactions.
Account: We’ll have two types of accounts in the system: 1)Checking and
2)Saving.
Customer: This class will encapsulate the ATM’s customer. It will have the
customer’s basic information like name, email, etc.
Card: Encapsulating the ATM card that the customer will use to authenticate
themselves. Each customer can have one card.
Transaction: Encapsulating all transactions that the customer can perform
on the ATM, like BalanceInquiry, Deposit, Withdraw, etc.
CASE STUDY
How to design a successful eCommerce system for
Amazon, eBay, FilPCart and Walmart