HNHacker News
TopNewBestAskShowJobs

chronark_

37 karma · joined October 15, 2025

context.Context at unkey.com
submissionscomments
chronark_··on Leaving serverless led to performance improvement and a simplified architecture
It’s faster for non-colocated customers too weirdly

I think cause connections can be reused more often. Cloud flare workers are really prone to doing a lot of TLS handshakes cause they spin up new ones constantly

Right now were just hang aws far hate for the go servers, so there really isn’t much maintenance at all. We’ll be moving that into eks soon though cause we are starting to add more stuff and need k8s anyways

chronark_··on Leaving serverless led to performance improvement and a simplified architecture
Thanks

It’s totally fair criticism that the title and wording is a bit clickbaity

But that’s ok

chronark_··on Leaving serverless led to performance improvement and a simplified architecture
Yeah that’s fair
chronark_··on Leaving serverless led to performance improvement and a simplified architecture
I cofounded it yeah

And yeah you’re right in hindsight it was a terrible idea to begin with

I thought it could work but didn’t benchmark it enough and didn’t plan enough. It all looked great in early POCs and all of these issues cropped up as we built it

chronark_··on Leaving serverless led to performance improvement and a simplified architecture
Oh we had it coming for quite some time and knew we would need to rebuild it, we just didn’t have the capacity to do it unfortunately.

I was working on it on and off moving one endpoint at a time but it was very slow until we hired someone who was able to focus on it.

It didn’t feel good at all. We knew the product had massive flaws due to the latency but couldn’t address it quickly. Especially cause we he to build more workarounds as time went on. Workarounds we knew would be made redundant by the reimplementation.

I think we had that discussion if “wtf are we doing here” pretty early, but we didn’t act on it in the beginning, instead we tried different approaches to make it work within the serverless constraints cause that’s what we knew well.

chronark_··on Leaving serverless led to performance improvement and a simplified architecture
I doubt they literally said “perfect for low latency APIs” but their messaging is definitely trying to convince you that they’re fast globally, just look at the workers.ckoudflare.com page
chronark_··on Leaving serverless led to performance improvement and a simplified architecture
Not everyone is born with experience in distributed systems
chronark_··on Leaving serverless led to performance improvement and a simplified architecture
I can assure you that was pretty close to the internal conversation lol

Not sure what the different takeaways would be though?

chronark_··on Leaving serverless led to performance improvement and a simplified architecture
We did initially but thought cloud flare was a better solution for scalability and latency.

We believed their docs/marketing without doing extensive benchmarks, which is on us.

The appeal was also to use the same typescript stack across everything, which was nice to work with

chronark_··on Leaving serverless led to performance improvement and a simplified architecture
Author of that blog here, happy to answer any questions :)