I suspect that starting your own version of the API is the Software Designer / Software Architect version of Programmers’ “I know best so I’m going to do my part of the code my way which is different from everybody else’s”.

Mind you, at the very least good Software Architects should know best, but sometimes people get the title without having the chops for it.

That’s totally not believable.

Blue shirt didn’t even mention Arch!

The expression “back to baseline” comes from Science and Engineering and literally means that something has gone back to the previous average flat level (for example: “the power line noise level spiked when your turned the machine on but is now back to baseline”)

Edit: not average, but actually specifically the original flat level below which things would not fall. Sorry, it’s kinda hard to explain in words but very easy to point out in a graph or a scope were it’s just this flat line to which things always return.

That expression makes sense if you’re talking about the rate of growth itself (i.e. the Lemmy rate of growth spiked at the time of the Reddit changes and eventually went back to baseline, since Lemmy is not growing any faster now than before the Reddit changes) but it doesn’t make sense if you’re talking about user numbers since the number of Lemmy users grew a lot with the Reddit changes and never went back to the average before them, not even close.

Your original post is not clear on which of those things you’re talking about when you wrote “back to baseline” and your subsequent posts are mainly talking about user numbers, giving the idea that that’s what your “back to baseline” is refering to, in which case you’re using that expression incorrectly.

A family of software development processes for teams, which focuses on cycles of quickly building and delivering smaller blocks of program functionally (often just a single program feature - say: “search customers by last name” - or just part of a feature) to end-users so as to get quick feedback from those users of the software, which is then is use to determining what should be done for subsequent cycles.

When done properly it addresses the issues of older software development processes (such as the Waterfall process) in siuations where the users don’t really have a detailed vision of what the software needs to do for them (which are the most usual situations unless the software just helps automates their present way of doing things) or there are frequent changes of what they need the software to do for them (i.e. they already use the software but frequently need new software features or tweaks to existing features).

In my own career of over two decades I only ever seen it done properly maybe once or twice. The problem is that “doing Agile” became fashionable at a certain point maybe a decade ago and pretty much a requirement to have in one’s CV as a programmer, so you end up with lots of teams mindlessly “doing Agile” by doing some of the practices from Agile (say, the stand up meeting or paired programming) without including other practices and elements of the process (and adjusting them for their local situation) thus not achieving what that process is meant to achieve - essentially they don’t really understand it as a software development process which is more adequate for some situations and less for others and what it actually is supposed to achieve and how.

(The most frequent things not being done are those around participation of the end-users of the software in evaluating what has been done in the last cycle, determining new features and feature tweaks for the next cycle and prioritizing them. The funny bit is that these are core parts of making Agile deliver its greatest benefits as a software development process, so basically most teams aren’t doing the part of Agile that actually makes it deliver superior results to most other methods).

It doesn’t help that to really and fully get the purpose of Agile and how it achieves it, you generally need to be at the level of experience at which you’re looking at the actual process of making software (the kind of people with at least a decade of experience and titles like Software Architect) which, given how ageist a lot of the Industry is are pretty rare, so Agile is usually being done by “kids” in a monkey-sees-monkey-does way without understanding it as a process, hence why it, unsurprising, has by now gotten a bit of a bad name (as with everything, the right tool should be used for the right job).

Look for a processor for the same socket that supports more RAM and make sure the Motherboard can handle it - maybe you’re lucky and it’s not a limit of that architecture.

If that won’t work, breakup your self-hosting needs into multiple machines and add another second hand or cheap machine to the pile.

I’ve worked in designing computer systems to handle tons of data and requests and often the only reasonable solution is to break up the load and throw more machines at it (for example, when serving millions of requests on a website, just put a load balancer in front of it that assigns user sessions and associated requests to multiple machines, so the load balancer pretty much just routes request by user session whilst the heavy processing stuff is done by multiple machines in such a way the you can just expand the whole thing by adding more machines).

In a self-hosting scenario I suspect you’ll have a lot of margin for expansion by splitting services into multiple hosts and using stuff like network shared drives in the background for shared data, before you have to fully upgrade a host machine because you hit that architecture’s maximum memory.

Granted, if a single service whose load can’t be broken down so that you can run it as a cluster, needs more memory than you can put in any of your machines, then you’re stuck having to get a new machine, but even then by splitting services you can get a machine with a newer architecture that can handle more memory but is still cheap (such as a cheap mini-PC) and just move that memory-heavy service to it whilst leaving CPU intensive services in the old but more powerful machine.