dev.to has a fairly scalable architecture in that we've built it so most traffic is cached statically on the edge via our CDN Fastly. In this sense we scale like a static site might, but any time content changes (like a new comment, or an update to the article, or any other freshness change), we start over and go straight to the origin. We also serve some dynamic content asynchronously with most requests. So there's still a lot of load on the server.
Like any Rails app, we hit different resource constraints and work through them as we scale.
In addressing fluctuations in resource bottlenecks we basically need to know what resources are being used up and what levers to pull when they get used up. Because of highly successful tech companies that have scaled this stack in the past, we rarely need to be all that clever, we just need to know the tools.
But despite this, we still have problems, of course. Code is tough. I want to share a few mental blocks I've needed to overcome to help lead our team in this regard. On to the lesson:
I've failed to re-read good material when we hit rough patches, erroneously thinking the problem is something new. Often it's the same basic problem in a new light. The next time we hit a particular rough patch, I will re-read a lot of great material. Read lots of stuff with an open mind, rather than purely reading to problem solve. You don't want to miss the forest for the trees when thinking this stuff through.
In this regard, the Speedshop blog by Nate Berkopec and other content from him has been very practical. The specific problems we faced don't need to be re-hashed here, but the advice not to think you need new material is the lesson here.
A couple DEV members who's stuff has also been helpful either on platform or on their personal blogs of years past:
Both definitely worth following, as are many more folks who post in #rails
Recently this old post from Mike was particularly helpful in terms of thinking through Heroku resource issues. Re-reading was critical because I'd gotten some of the important conclusions mixed up in my memory.
The future holds many challenges. For example, we have not had Postgres as a bottleneck in a while, but in the future it will become one again. When that happens, rather than scramble to learn new things in that moment, the best immediate action will be to thoroughly re-read old material that has helped us get over a few hiccups in the past. From here we can go on to learning new things, but we cannot have the fallacy of having fully learned and retained old material for indefinite new problems.