Well if you're distributing requests over multiple servers, I wouldn't call that a monolith.

You're mistaken then. Monolith is just project organization. Think microservices and then realize the monolith is on the other end of the spectrum. It's in the name.

You keep posting this. A monolith is a software architecture. It says nothing about there being one instance of that monolithic process or a billion any more than "microservice architecture" becomes untrue unless you have k instances of any particular service.

It's like saying "this thing says it is built as a suspension bridge, but there are ten of them, so I wouldn't call it a bridge."

Here is some Microsoft documentation describing how a monolith application can be deployed behind a load balancer[0]. HTH

[0] https://docs.microsoft.com/en-us/dotnet/architecture/contain...

If your definition of a monolith refers to a singular server, then I've never worked on a monolith in my life. Even the crufty old ASP apps I used to work on weren't monoliths.

This would also mean that deploying a microservice architecture onto a single server, using docker for example, would be considered a monolith. Or even better, any application that leverages a database on a separate server is no longer a monolith! That's way easier than rearchitecting your whole app.

I've never come across a definition for monolith in the context of software that had anything to do with the actual infrastructure employed

Nevertheless, that's a pretty common term when the compute portion of the application is a single tier, but that doesn't mean that the tier can't scale over many stateless compute nodes.

I believe you're alone in using that definition

Monolith refers mostly to the code, not the distribution of app servers. There's one app (a monolith) served multiple times.