alt Hacker NewsThey don't have a monolith: they have a service that has a restricted domain of responsibility matched to the team that runs it.
There is nothing magic about their queue service, and it seems correctly tuned to the complexity that they've got to cover: yes, just like most queue implementations, it will get different types of messages (events). If anything, their previous implementation was too complex which caused lots of waste.
With hindsight, they should have evolved their original architecture into exactly what they pivoted to now: better fault tolerance in "processors" of different types.
I would hope that my general rule of "only solve exactly the problem you have in front of you" would have avoided the approach they took, but engineers love to abstract away things and introduce indirection layers and add accidental complexity that way. And ofc, "microservices great, me want microservices" too :)
Again, I am not saying this as a slight: I believe many of us have learned the limits of microservices by, well, living through them :) And now we tune our abstraction layers differently.
> They don't have a monolith: they have a service that has a restricted domain of responsibility matched to the team that runs it.
Except, for lack of a better definition, that is a monolith.
Which there's nothing wrong with one if that's what you need.
> I would hope that my general rule of "only solve exactly the problem you have in front of you"
True. Which was the issue with everyone jumping on the microservice train, most of it was about solving problems nobody had.
When you really need an independent service, go build an independent service. Call them micro if you like (again, no good definition for what microservice or monolith actually mean).