Kafka vs. RabbitMQ vs. Messaging Middleware vs. Pulsar 

sounds like a good thing for you to work on and post yourself on own channel

@@jayrigger7508 why so arrogant? He literally suggested a potential improvement and you come by and say "Just do it yourself".

Wow, didn't know of it. Specially the object store seems cool

@@rogsiel While i haven't used their object store yet, i am using the key value store to persist actor's internal state, that way i don't need to rebuild it (event sourcing pattern) before processing the requests. The only issue i have with nats is the lack of backup / recovery options, seems like replication + a recovery cluster is the preferred way.

oh that's cool . Will definitely look into it. Having pub/sub and object store together is interesting. I'm already doing the exact same thing for backups and persistent data.

Nats doesn’t have partitioning, and apparently never will. You can emulate it with channels, but you won’t get rebalancing, for example. So it’s more like a cousin to Kafka

@@nikitamyazin6586 Are you talking about jetstream topics or old nats streaming server (stan)? You can have multiple consumers on the same topic and as long as they belong to the same group they will all act as one. You can also partition topics, based on some (hashed) key and split incoming traffic across multiple workers, so that the same topic always reaches the same worker, which is very useful with actors. I'm sure you've seen this and we're just thinking of different kinds of partitioning. docs DOT nats DOT io/nats-concepts/subject_mapping

Do you know anything about that, I'd certainly be useful

No 😂

vendor lock in ecosystems get outta here

They were not made obsolete, they just solve different problems. Kafka and RabbitMQ are very different and you wouldn't use them interchangeably. Huge streaming volume = Kafka Complex pub sub = RabbitMQ A new solution arises as the new problem becomes significant enough and is not solved well enough with existing tech.

I've spent a few years with a RabbitMQ backed system on-prem. Granted, on-prem, on a VM on desktop/laptop, and on-prem in a VM in a llocal data center are all about the same thing these days. Failure modes and recovery aren't always obvious (especially if the VM is frozen and moved), but it's at least a decent solution and might be a great one depending on your circumstances.

Persistent sharded logs as the source of truth 🥵

Or giving you freshest framework/tool so you can rewrite your application again for no reason at all 😅

@@oskarszwajkowski Trend casing, when you need an excuse to not do real work

U are just mad because u cant handle more advance concepts than programming.

​@@matonolo "More advanced concepts than programming".. what?

Event-driven microservice architecture is important to know if you want to work in backend. Not sure why you're acting like this is impractical knowledge.

There's a transcript option