The small web: scalability and building for realistic loads

I got some spam this week:

We guarantee at least 20 to 100 qualified leads every month … Imagine 80 warm leads turning to 55 meetings and converting 25 into loyal clients—what would that be worth to your business?

Yes, imagine that.

What a nightmare that would be.

55 extra meetings a month?

2+ extra meetings every single working day?!

I can’t imagine what sort of scale of business I’d need to be running for that kind of sudden increase to be a wise idea (leaving aside that there’s just no way that these are genuine, high quality, leads, for the kind of thing I do).

At the moment, I turn away more work than I take on, precisely because I don’t want to scale decoded.legal.

Truth be told, I’m a bit afraid of doing so.

But if I did, I’d be doing it sensibly. Gradually. Responsibly.

I take the same approach with our systems.

I don’t need servers which I could immediately scale to serve massive increases in traffic volumes or users.

So I don’t. By design.

The server hosting this page is an aging Intel NUC. It fares pretty well, even with the occasional spike of traffic from the fediverse.

The server hosting my fediverse instance was a Raspberry Pi but, at the point it was struggling to cope, I switched it to another aging Intel NUC. Now, it seems to plod along just fine.

Does it matter to me if occasionally there’s more traffic than they can momentarily handle? Nope.

I could increase our Internet connection to 1Gbps and, for a time, I really wanted to. But what I have - half that - is more than sufficient.

I don’t need kubernetes, or an infinitely scalable cloud service, or anything like that.

I go for just a bit more than I need in the foreseeable future. I don’t have a need, or see a point, in spending time, money, and effort on being able to scale up massively, immediately, at the drop of a hat.