What about "scale" and "performance" ?

SpringBoot, and all other frameworks publicise the fact that they can handle tens of thousands of requests every second.

The applications I have worked with, and I am assuming this is true for most applications sitting on the internet, and the internal applications used companies, none have ever needed that kind of scale.

Even 100 requests per minute is a lot of load. Don't manage to hit that many. Plus, if you really look at it, the whole "keep the cache warm" or "preload all the configuration" is good for large load applications. For the small ones, a few milli seconds do not matter.

So, I am willing to take the bet that holding data, and hence memory, may not be required. The JVM is really good at garbage collecting memory. So, lets use it to our benefit.

Also, if we do not maintain too much state, we can bank on functional programming, and scale out architecture, if we really start hitting performance. And, as is required by internal applications in the enterprises, the scale out gives us the high availability check mark.

I also rely on using docker compose . So, deploying more of light weight services in a docker swarm is easy. As is expanding the swarm dynamically.

The core assumption, at this time, since I do not know the end result, and am building this out as you, the reader, are reading it, is that my application is not internet scale. A few thousand transactions a day is as far as I will plan for.

But, maintenance of the application should be cheap, because, in all probability, we will revisit this application only a few times a year, in an optimistic situation. And every time will be a different set of eyes.

So, let's get started, and explore the Http Server API next time, and see where we need to begin.