Introduction

This article describes how to build a custom URL shortener service using Azure’s serverless platform with Azure Functions and Cosmos DB. I had this idea after I recently read Jussi Roine’s article, where he built a URL shortener service (such as bit.ly) using a serverless Azure approach, an approach he led with Azure Logic Apps and a custom web app. As I was reading his article, I realized that building the same solution with Azure Functions and proper use of input and output bindings, can yield a highly elegant solution. And so, I embarked on a journey to see just how smart can such a solution be.

I also wanted the solution to be ultra-scalable and achieve very low latencies in response to queries, so I chose to use Azure Cosmos DB as the storage solution. Cosmos DB is Microsoft’s proprietary globally-distributed, multi-model database service. Cosmos DB guarantees less than 10-ms latencies for reads and writes at the 99th percentile, so it was a natural choice.

The Requirements

The URL shortener service should have two endpoints:

1. A URL registration endpoint, which allows clients to register shortened URLs (often referred to as vanity URLs) with their redirection target.
2. A URL redirect endpoint, where web browsers can issue GET requests using the vanity domain and receive a redirect to the target URL.

Also, as stated above, the service should possess the following runtime qualities:

1. Very low latency in response to redirect requests.
2. Ultra-scalable in terms of both request throughput and geographic scalability.
3. Relatively cheap to operate, with cost scaling together with request throughput.

The Solution

To answer the above requirements, I decided to proceed with the following solution architecture.

URL Shortener Architecture

Other than meeting the functional needs, this architecture is also aligned with the desired runtime qualities.

1. Cosmos DB guarantees less than 10-ms latencies for reads (indexed) and writes at the 99th percentile while allowing virtually unlimited throughput (with proper scaling). The only mechanism that can improve this latency is an in-memory cache such as Redis (or Azure Cache for Redis). However, it does require extra work since Redis alone cannot provide the desired persistence consistency. We can combine Redis as a cache mechanism and Cosmos DB for persistence to get the best of both worlds; however, that is out of scope for this article.
2. We can quickly deploy Cosmos DB in multiple geographies at a click of a button, scaling our data worldwide.
3. Azure Functions is a lightweight solution with minimal overhead. The only downside to Azure Functions (and virtually any serverless platform) is the cold-start time, which can be very long. However, Premium and Dedicated hosting plans solve this problem on Azure (at the cost of increased financial expense).
4. Both Cosmos DB and Azure Functions can start cheap, and grow in spending as the required throughput increases.

#cosmosdb #azure-functions #serverless #cosmos #azure