I am the founder and webmaster of dev.to, a platform where programmers write articles like this one, have discussions and make friends. It is a lot of fun growing the application and growing the business. On the technical side, we've tried to keep things straightforward as the app grows in complexity, but because we've purposefully built a pretty simple solution and have not encountered any serious scaling issues along the way.
The challenges that we do regularly deal with revolve around delivering the right user experience, keeping up our communication on point, and generally picking the right challenges to take on from day-to-day. Our team is up to five devs and one person who focuses mostly on the business side, though we all chip in wherever we can.
In addition to the very real issues of growing the platform and our communication structures, I really like to play around with solutions to potential future issues. I usually do this on weekends, when I don't have to justify the use of my time to anyone, not that we are very heavy handed with this to begin with. So right now, I'm exploring the idea of sharding our database and serving the core application from multiple regions across the world to cut down on the latency of database reads when requests hit the origin server. I've done the research and chosen the libraries we would likely use to make this possible, and generally thought through how we might go about implementing our solution.
But this is a solution to a problem we don't have, so we won't be implementing any of this. I knew that heading in.
This is an exercise, and a very personal one at that. Eventually we'll probably need to start thinking along these lines as a team, and I'm excited for when we do. But for now, we will keep trying to build simple solutions to problems we have and use our imaginations to come up new features and optimizations that will please our users.
At the moment, we have a pretty nice monolithic application that makes good use of our CDN, and our users appreciate the effort we've put into performance optimization. And that's about it.
Top comments (11)
From In the Plex (which I know you've already read):
Basically, DEV will be Google soon. Hurrah!
Well... duh. But seriously, it's in my nature to have my head in the future (or in the clouds) and the important part at this stage is resisting the urge to actually work on the problems this far ahead of time.
Correct me if I didn't understand you but, you thought about the how in your potential scaling issue. If this problem occurs in the future, you already know what solution you will apply.
How do you decide when you have to apply the solution? Do you have arbitrary metrics? User feedback? Is it something along the lines of: If you ask yourself if you need this, you don't?
Curious about the process.
Good question. This is actually more about product evolution than it is about scale. Right now, we've built our product to, more or less, scale to any possible number of users. It leverages shared cached resources a lot. But as we evolve, we're trending more towards personalization. Even just the current user's profile on the home page was a product evolution that could potentially degrade the user experience.
As we add more features like this we trend in the direction where it could make sense to distribute our data. At some point, this will be easier than managing our current solution. That's when this sort of thing will make it into the app.
At least that's how I see it now. Things change all the time. This is something I'll revisit whenever I am inspired to and perhaps a teammate will jump in and have some ideas. I'll add that in a lot of ways, this app is an excuse to concretely think through this problem for some future unrelated endeavor. I'm not very good at learning about things in completely abstract terms. This kind of exercise helps with that.
Hey Ben - Great post on deciding when to solve scaling problems from a startup engineering perspective. Coincidentally I wrote a similar post yesterday about a new product launch but with commentary around thinking about scaling in a startup too.
astronomer.io/blog/apache-spark-st...
I'm looking for opportunities for us to start cross publishing semi-technical posts like this one or deeply technical posts on dev.to as well.
If you're looking for opportunities, they're here for you. If you want to start an org account like dev.to/clarifai, talk to @jess (jess@dev.to)
The posts on your blog seem perfect for the community. What we try to provide with the org account is an opportunity to have your branding and credit on all the posts while still letting folks consume and comment on the content here.
I believe the key to scaling correctly is avoiding a reduction in performance of the current features. New features should be treated as a new concern, but very often they end up breaking existing features. Either you need a way to test out new features in scale, or have a rollback strategy should it not work as desired.
The reason is primarily for user retention. What a service has now is obviously working, and attracting new people. During a growth phase there isn't a need to add new features, since obviosuly the current ones are working. But too often I see companies try to keep piling on features in this phase instead of worry about scaling. This has the double effect of putting a new kind of load on the system, wile also trying to deal with the influx of people. It may end up pissing everybody off and putting a quick end to user growth, or actual reduction in user base.
Just the right approach I'd say. Start simple. Don't optimize as long as you don't have to. But start DevOps'ish and be careful to deal with Dickersons Hierarchy of Reliability (david-merrick.com/2017/06/26/dicke...), especially the lower layers (monitoring). Keep eyes open to know how to address scalability issues as soon as they arise but even more keep eyes and ears open to see them when they actually start arising, to be able to figure out bottlenecks, scalability limitations fast. In our experience running a modestly sized system that has seen 15+ years of growth, fixing scalability issues is not trivial but in most cases it's way easier than actually finding scalability limits using good instrumentation. Make sure your application has this baked into from day one.
This inspired a great talk by Laurie Voss at DinosaurJS.
Oh yay, Laurie told me he was planning this but I hadn't seen it.
So... Dev.to won't adopt Preact.JS for a new level of UX?