1. What is a URL shortening system?

    URL shortening is used to create shorter aliases ("short links") for
    long URLs. Users are redirected🔄 to the original URL when they enter
    these short links into their browser.


2. What's the main value? Who needs such a system and why?

    URL shorteners value:
        1) Make links that are easier to share.
           Short links save a lot of space when displayed, printed, messaged,
           or tweeted🐣. Users are less likely to mistype shorter URLs.
        2) They let businesses track marketing campaigns and other incoming traffic.
        3) Shorter links seem more trustworthy.

    Both businesses and the public have a use for this service, but
    businesses more so since the analytics they get from it can help them
    make important strategic decisions and increase revenue💸.


3. Describe The main mechanism of work👨‍🏭 and system components.

    The main mechanism of work is an api server that has two routes:
       1) Get the long url corresponding to a short url
       2) Create a short url for a long url

    We can and should have more then one api server since this system will
    come under a heavy load. This info wasn't provided in the assignment,
    but can be deduced since this is a common system design interview
    question. Also it's the holidays and I didn't want to bother people with
    unnecessary emails🎉🎇. I'm also assuming we don't want to expire these
    links, but if we did we could add an expiration date field to our db
    collection and just check the expiration date when getting them and also
    run a daily cron job to see how many links have expired (or something
    like that) and delete those.

    The tiers of the architecture are:

        1) Client tier - Our angular app
            This scales easily since we can prerender the app and host it on
            a cdn (Amazon CloudFront, Google Cloud CDN...)

        2) Server tier - Our api
            This can also be pretty easily scaled since our apis are stateless.

        3) Database tier - This is the tricky part.
            At a certain point vertical scaling becomes impractical, and
            later even impossible, so we need to think of a distributed
            solution. We can use sharding on the long urls as a sharding
            key, since the long urls should be unique and have a unique
            corresponding short url. We can traffic the requests to correct
            servers by using a load balancer

    We can also add a caching layer and a rate limiter.

4. What do you think are the main challenges in implementing and running the
   system

    The main challenges are regarding scalability, availability and fault
    tolerance. Without considering scalability issues, the system is
    relatively easy to implement. Because of this you must have multiple
    database servers. This in turn means we now have to think about
    consistency of the data. How do you consistently create short urls and
    keep the {long url -> short url} function bijective? You would have to
    check before writing to the server atomically. Also if you have a lot of
    short urls in the database you might have a high number of collisions
    when generating short urls.


5. Try to suggest some ideas for advanced features.

    - Allow users to make their own profiles to track the links they
      shortened and how much those links were used. Not only the admins.
    - Allow organizations to group urls by certain parameters,
        so they can later extract better analytics
        (grouping types of urls, comparing the groups...)
    - Permissions based on location of person accessing the link content
    - Analytics based on location of person accessing the link content