[ramenmeal]

In your monolith if you offload a request to a queue and have a background process processing the queue messages, what do you call that module processing messages? Is it a component of your monolith? I think a lot of teams would call it a microservice, I could see some people considering it a component of a service.

Unless you're confounding microservices w/ async architectures and saying to drop asynchronous patterns like this all together.

[b20000]

I don't need another process. I can use a thread.

If the teams you are talking about never heard of threads and only know about microservices, then there is something seriously wrong with their CS education. Maybe they all were hired via leetcode. That could explain it.

I'm not confounding anything. Distributed programming has its applications and uses, but if you don't have a good reason to use it, then don't, and use a thread in a single process for background processing.

[oflor]

And how does it recover incomplete tasks in case of sudden power outage? Microservices use persistent message brokers for that, which are not there in threads. Or are these monoliths all treated as pets with redundant power supply and network lines?

[sebazzz]

Thread does not imply no queue or no persistent storage. In fact, if you use something like Hangfire you already have that.

[strokirk]

My CS education (Stockholm, KTH) didn’t include anything about web service architecture, and information about threads was about how they are implemented in the OS at a low level, not how to use them effectively. I think this stuff is normally picked up after working in the industry.

[esprehn]

The background process is just threads in the monolith, that's not a microservice. That a different pod running the same code might pick up the async task doesn't make it less of a monolith either.

[ecshafer]

I have never seen what you are describing called a microservice. Microservice always means some kind of independent application in its own runtime.

[marcosdumay]

What are you talking about?

What makes it a service soup is the soup of services on the other side of the queue processor. If those components weren't services, the application would be a monolith.

Anyway, there many reasons to organize your code on services, and McDonalds is large enough for them to be perfectly valid. But if you take a closer look, those components on the article aren't the ones that do anything, they are just new queue processors that may or may not finally deliver your messages to the destination. That's an irksome architecture.