Short URL Service Design V2


V1 Design doc: https://www.bo-song.com/short-url-service/

User journey in V1

Get link

  1. user issues /{short_link} request to server
  2. server redirects every page to redirect.php to further handle it.
  3. Server checks the DB, if the {short_link} exist, goes to step 3, otherwise goes to step 4
  4. server sets 302 status code with the {original_link} in response header <END>
  5. server returns the index page with the {short_link} fulfilled in the form.

Post link

  1. user enters the index page by either requesting / page or being redirected from a /{short_link} page where {short_link} does not exist in the DB
  2. user enters the {short_link} and {original_link} in the form and submit to server
  3. server write the record to DB; clinet reset the url in the browser to the /{short_link}

Problems in V1:

  1. In the redirection stage, the server reset the response header to instruct browser to the new location.
    1. Pros: simple logic, fast turn around time.
    2. Cons: low extensibility, hard to add more client side behavior before redirecting, such as integrating with the Google Analytics for link usage tracking.
  2. The bosong.link uses a same server and DB with bo-song.com blog.
    1. pros: save money, save resources
    2. cons: single point of failure.
  3. Apache mod url rewrite is used to remapping short url to the redirect.php page.
    1. pros: it works
    2. cons: the mod rules is hard to maintain.

Solutions

Browser redirects the page

Sample code

When user lands on the /{short_url} page, server always returns the single index page. The index page then parses the {short_url}, sends request to the server to request for the long url.

Probably we need to set up a new subdomain to handle the API request, such as api.bosong.link/

Set up separate docker server

Use docker for easy migration and maintenance (yes, migrate together with the DB?need to verify)

Kubernetes

Kubernetes is like borg in Google; Docker image is like mpm package in Google.

https://www.digitalocean.com/community/tutorials/an-introduction-to-kubernetes

Using MEAN Stack

MEAN (MongoDB, Express, Angular and Node.js) is relatively new regarding to the LAMP (Linux, Apache, MySQL and PHP) stack. One advantage of MEAN is both backend and frontend use the Javascript language, which means the learning curve and maintenance much easier. (reference)

In the V2, the shortlink service will switch to the MEAN stack and contained in docker.

MongoDB vs MySQL comparison

MongoDB is NoSQL and MySQL is SQL (relational database). So, what’s the diffrence? (reference)

You need to use SQL if you need ACID compliancy (Atomicity, Consistency, Isolation, Durability) and your data is structured and unchanging . Such as bank account transactions, stock broker DB. Relational database is not easy to scale horizontally when rows in a table grows. In other words, it’s not easy for a relational database to shard and partition.

You need to use NoSQL DB if you store large volumes of data without structure, use cloud computing and storage, and rapid development like agile.

In the shortlink case, we do not need ACID compliancy, and we should focus on the scalability cause the shortlink volume could grow rapidly.

Thus we choose MongoDB.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.