After building the Notification System, I observed that shortening of URLs before appending them in SMS/Whatsapp template was either failing or taking a long time (35-60 minutes in some cases). I got to know from Architecture squad that the 3rd party URL Shortening Service's tier that we were using was capped at 80TPM. This was clearly a bottleneck and after a lot of to and fro, I was admitted into the Architecture Squad itself, and given this new task of creating a high througput URL Shortening Microservice.
Taking inspiration from Tech Dummies Youtube Channel's video, I came up with the architecture of this service that would fit in our company's tech stack.
First of all, the scalability and uptime of this service is handled by Kubernetes and its inbuilt Horizontal Pod Autoscaler. The Architecture: on deployment, pods would request a range start from MongoDB with the range configured inside the service, and once the start is acquired, the document is locked with a flag. In case of re-deployment, to stop same range from being picked by replicaSets, rolling upgrade was configured as deployment strategy! The range start fetched from DB would be converted to base64 serving as our shortened url and stored in DB with the incoming long url. To ensure 2 consecutive requests borne varying short urls, a huge number(shorter than the range) would be added to current number causing base64 output to be hugely different. And to ensure that all numbers in a range are being utilized, Modulo Arithematic is used, when number exceeds the limit, take mod with the range and continue the operation.
This service achieved 12000TPM in its minimal configuration and has been adopted as the official URL Shortening service being used by the whole organization now!