←back to thread

1226 points bishopsmother | 2 comments | | HN request time: 0.419s | source
Show context
ChrisMarshallNY ◴[] No.35047455[source]
Well, I feel for them. Scaling up is a bitch.

I've been lucky, in the past, but a lot of that, is because I have "overengineered," and the tools/frameworks have advanced to meet the new demand.

I am in the middle of a complete, bottom-to-top rewrite of the app we've been developing for the last couple of years. It's going great, but making this leap was a fraught decision.

It's mainly, so I wouldn't have to write a post like that, in a year or two.

We spent all the time refining it, until we had what we wanted, and it worked great on our small test team.

Then, I loaded up a test server with 10,000 fake users, and tossed the app at that. To be fair, we don't think we'll have even that many users for quite a while. It's a very specialized demographic.

* SOB *

It no do so well.

At that point, I had to decide whether to fix the issues (they were quite fixable), or revisit the architecture.

The main issue with the architecture, was that it was an "accreted" app, with changes gradually being factored in, as we progressed. The main reason for this, is because no one really knew what they wanted, until we ran it up the flagpole (sound familiar?).

The business logic was distributed throughout the app. That was ... ugly.

I envisioned myself, a year or two down the road, sucking on a magnum, because the app had turned into a Cruftosaurus, and was coming for me in my nightmares.

So I decided to rewrite, as we hadn't done any kind of MVP or public beta, so we actually had the runway to do this.

I refined the entire business logic of the app into a single, platform-agnostic SPM module, which took just over a month, and have started to develop the app around that. It's pretty much a rewrite, but I am recycling a lot of the app code. We also brought in our designer, and he's looking at every screen I make. It's working well for him.

Like I said, it's going great. Better than I expected.

I know that I have a huge luxury, and I'm grateful. I can credit a lot of that, to doing some stress-testing before we got to a point where we had a bunch of users to support. I was able to go in, and go all Victor Frankenstein on the model.

The result, so far, is that this thing screams, and you don't really even notice that there's that many users on it. The model has already been proven (that SPM module), and all we're doing, is chrome (which is a ton of work).

replies(2): >>35048055 #>>35049493 #
1. machiaweliczny ◴[] No.35049493[source]
Don’t know about expected usage but 10K rows seems like low number to me. If you mean 10K req/s then perf starts to matter but usually it’s SQL queries that fail first if you have 100K+ rows. In general good caching solves most of stuff + read/write separation. That’s all from my poor experience.

What I mean is that these scaling problems don’t have much to do with app logic but having nice core is good so :thumbsup:

replies(1): >>35050534 #
2. ChrisMarshallNY ◴[] No.35050534[source]
10K is a rounding error, to most folks, around here.

The app (and the demographic that it Serves) are very security and privacy-conscious, so security and privacy are the main coefficients. Most folks would be disappointed in how few features the app boasts, as each feature is a potential compromise. I'm glad to have low usage, as a result.

I wrote the backends, as well as the frontend, and have avoided third-party dependencies, all around.

It seems one of the first casualties of fast scaling is security.

I really didn't want to take any chances. An overly-complex architecture is begging for security compromises.