To give a brief intro - Blanq is a custom URL shortener
that supports link redirection, analytics and more.
It is primarily a DB write-heavy application since analytics requires every redirection to be saved in the database.
When I first started, this is how my stack looked like on Digital Ocean:
Pretty basic I would say but, it made sense since the only user was me.
After posting on Indiehackers, I landed up a couple of pretty large customers - which was totally unexpected.
These customers had in total a million followers on social media each.
It hit me then! My app cannot handle the huge amount of traffic coming my way.
I increased the droplet size to $25 that provided me with enough headroom in case there was a spike in the traffic.
And it worked!
It could now handle 200 writes per minute without dropping any request.
But...
It was not perfect. I was constantly worried about losing database or getting hacked. I had no confidence in my backup script. I did not want to part away with my data by using third-party backup services. They were also a bit expensive. Also, I was not sure about how my application was performing in the real world.
So I,
Though Managed database's entry plan is not the best - it is good enough to start with and, a lot better than running my own cluster.
I reduced the instance size to $15 plan since I no longer had to run MySQL DB. I plan to further reduce it to $10 instance since it provides me with plenty of headroom for growth and spikes in traffic.
My current costs are $30 per month and the application serves 400 requests per minute(DB writes) during peak traffic hours. Quite decent I guess.
What's next:
I prefer to keep things simple and postpone as much as possible to save costs and time.
It was also a great learning experience for me in the last 4 months and a roller coaster one.
Thanks for reading :)
👉 Try Blanq to shorten your links.
Have you looked at using AWS' serverless offerings? Your service looks like it would be a perfect match for using API Gateway, Lambda, DynamoDB. Instead of having a bare minimum infrastructure. You would have no infrastructure.
You wouldn't have to deal with adding a MySQL failover slave. I think you're response times would be lower and you're costs will definitely be lower.
Really! Let me check. The only reason I have not moved to AWS is that customer domains are point to my instance IP address and it will require them to update that. Not an easy thing to followup with them.
I used to use Digital Ocean a long time ago. Once I figured out AWS, there was no going back. My $10-$20 a month droplet changed to $1-2 in AWS. I replaced my droplets with a static website and API Gateway / AWS Lambda. The thing I like most is that I spend my time writing code and not managing infrastructure.
Since your app is write-heavy, careful with how many indexes you actually add. The more indexes you have, the longer it will take to insert a row. It won't matter right now, but as you scale, it will. Thought I'd mention it since you said "indexes on all columns." 👍
Also, look at multi-column indexes if they make sense for your use case rather than multiple single-column indexes. Although in some cases MySQL may choose to go for a cross-index intersect, if you're querying a table across multiple columns with high(ish) cardinality on each (or several), a single multi-column index will almost certainly give you the breathing room that you need for a long, long time.
I am sorry - meant indexes on a few columns that are read often and used in where clause. I will check out multi-column indexes - I have not heard about them.
Thanks.
Nice write up thanks. This problem is often used as an interview question for engineers, so there's a lot of discussions around on what the architecture should look like - but you probably know that already.