[cjfd]

Things like message queues and asynchronous events are available for your favorite programming language for in-executable use. You can then do things like running them on a thread pool that has the same number of threads as your machine has cores.

[jayd16]

So you're not only suggesting monolith, but single instance? In process and non-shared queues only? No load balancing across monoliths?

[cjfd]

Not necessarily. That one can have these tools in-application doesn't mean one cannot combine this with some form of RPC as well. Especially whether one needs load balancing or not seem to be a completely orthogonal issue.

On the other hand, why not a monolith and single instance? If one uses a performant language one would be amazed how much can run on a single machine. If one expects growth one should have some plan to scale, sure, but if one does not go for shenanigans like running queues and the like between applications using some form of RCP one might get amazed how much your single monolith can actually do. All this extra networks stuff and so on is not exactly free.

[jayd16]

>On the other hand, why not a monolith and single instance?

Single points of failure are bad. I agree its orthogonal, which is why I inquired further about the, imo, odd suggestion.

[ratww]

Running a single instance doesn’t mean not having a backup.

[imwillofficial]

I didn’t read any of that. I read it as more tools in the toolbox.

[jayd16]

Without single instance, an in process queue doesn't provide the same kind of functionality that a shared queue does and would probably introduce split brain kind of problems, no?

[imwillofficial]

Right, you’re taking it as a suggestion, as in a positive nudge to single instance monolithism. However, I read it as merely making GP aware of other options that are on the table.