High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Concept:

The goal of this project is to design a service that shortens long URLs into a preferrable 8-bits long URL which can reduce that considerable space in writing long URLs. A URL shortener shortens a long URL into a concise, easy to memorize, easy to share and aesthetically pleasing short URL.

Design:

The URL shortener takes a long URL as an input from a user and returns a short URL. When a user sends a request whose body contains a long URL, a service (API) takes the long URL and create a unique short URL, the created short URL is a path on my domain and it must be unique so as to prevent two long URLs being linked to the same short URL. for example,

USER LONG URL: "https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcSGxwl4fhem6m2urbLPsROL7UHP2tjF4CowszALXe5IwDIMG7C2VdCqSyLCsNi4mrqWuKJgVE215SQCpX3TOTQSUgwhOnN_kBr2FB6omLvWww",

EXPECTED SHORT URL: https://my-domain.com/aXb324

Geographically, this program should be able to handle multiple users from different parts of the world. Users are expected to be able to communicate with this program via a mobile app, a desktop app, a web application through an API.

Active Users: 500,000 - 1,000,000 daily active users

1,000,000 - 3,000,000 monthly active users

Read vs. Write: 100 : 1

Queries per secs:

Read: (1,000,000 users * 100 reads) / (24 * 60 * 60) = 1157 QPS
Write: (1,000,000 users * 1 write) / (24 * 60 * 60) = 11.57 QPS

Storage: (Assuming every users have at least 5 long URLs stored on my DB for 3 years)

Number of objects: 5 * 1,000,000 * (3 * 12 * 30) = 5.4B
size of each objects = 2000 bytes
Total object size = 2000 bytes * 5.4B = 10.8T

Throughput:

Read: 1157 QPS * 2000 bytes = 2.314M = 2259 MB/Secs
Write: 11.57 QPS * 2000 bytes = 23,140 = 22.59 MB/Secs
Cache (following the 80%-20% rule): 2259 MB/S * (60mins * 60secs) * 0.2 = 1588 GB/hr

Security:

SQL injection: SQL injection is the placement of malicious codes in SQL statements through a web page input. To tackle this problem, every input by the user is validated before executing.
DOS and DDOS attacks: DDOS attacks are malicious attempt to disrupt a server, service, or network's normal traffic by overwhelming it with a flood of internet traffic from multiple, often compromised, sources. With the introduction of a rate limiting technology, multiple request from the same IP address, same user are blocked from interacting with the database.

Reliability:

Using the replication technique, data stored on a server are replicated to another server, this secondary server will be updated daily and can act as a backup server in an event where the main server is down. The database can also be dumped into a HDD on a two-days basis.
Having to get another server of the same size with the main server will bring about an increased cost and storage. Now, we are looking at a total storage of about 11T per DB.

Scalability:

When daily users increase, there will be an adoption of vertical scaling. We increase the performance of our current servers by increasing the space, RAM, and processors.
If that is not enough to handle the data traffic and users, then we scale horizontally, adding one or two servers with increased efficiency.

Component communication: There are different components in this program, and they communicate in different ways. The client component communicates with service layers by making REST API calls to the API endpoints. And the API endpoints communicate with the data layer by directly accessing the database.

A URL is submitted as a web page input which is send from the frontend as JSON data as a request to the appropriate API endpoint. The submitted data if it does not exist on the database is then transferred to the shortening service else, a response containing both the long URL and the short URL is returned via an API call from the DB to the user.

Components in this program communicates over the internet and uses HTTPS through REST API calls as the protocol. Requests and response are in form of JSON data.

Communication is synchronous and they wait for response to be sent before they continue to run.

Storage Level Responsibility: PostgreSQL will be used as the main database, and Redis cache will be used to cache data so as to reduce traffic on the database.

Data persistence: The storage level ensures that data are properly kept. In this case, it is the responsibility of the storage level to ensure that when a long URL is sent as a request, the short URL generated alongside the long URL are stored in the Database
Data Retrieval: The storage level ensures that data are readily made available when requested by the API. Only requested data will be sent back tot the user.
Performance: Considering the fact that there will be more read than writes, a cache will be used to increase performance and store frequently used data. Since written data will not be updated, the strategy used will be cache-aside (lazy loading).

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10