How to build your own serverless URL shortener service

By Mohamed Barakat

We used to shorten URLs for our different reminders and notificationsduring the selling process, we have many notifications to be sent for collecting data and informing about a specific state,we send those notifications as emails and SMSsso we went for bitly mainly because of SMS restrictions,but recently we started using it for emails as well.This was because, in Mandrill, long links can cause issues appending tracking parameters correctly, leading to incorrect tracking statistics.Exceeding our quota caused all the services to rely on shortening via

in a way or another to fail, which means:

  • 248 failed requests.
  • 29 users got affected on time.
  • 28 users got an error message (failed request) and couldn’t retry it, because the endpoint was constantly returning 500.
  • We got approx. 100 sentry issues reported. Given that we retry 3 times, so it's around ~40 mails/SMS that could not be sent until then.

A simply upgrade to another plan was not really reasonable as it would only provide us with 3k additional links for 199$/month!
While Bitly’s enterprise plan could be a solution, it starts at $15,000 per year!

Image for post
Image for post


A SaS alternative to that we also considered was it also was too expensive for our use case,

specifically considering what kind of features we actually need.

Upgrading Bitly was not helpful, it was only 3k links for 199$/month! So we hot-swapped over to rebrandly as a temporary solution still using bitly as a fallback. But monitoring the increased shortening needs we realized the extended quota needed to be increased several times during a months period

In the end, we decided to build our own URL shortener service.


I had a technical meeting with our Lead Engineers, Carsten Wirth and Ilyas Amezouar, we decided to build our in-house service to shorten URLs,
during the PEW, using a serverless approach.

Why build a service like that in-house?

  • More adjustable.
  • More scalable in regards to our needs.
  • No third-party SaS being used.
  • You can have your own branded link, without paying extra for it.
  • Our Engineering kitchen is full of skilled chefs 👩‍🍳👨‍🍳.
  • Things that you might not think about and come out of the box –
    we had a similar case that will be mentioned later (the check for already existing URLs was not threadsafe).
  • The effort in terms of time, requirements, maintenance, and usage.